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CUTTING  A  PATH  TO 
QUALITY  THROUGH 
CONCURRENT  TEAMWORK 

Remaining  Alive  and  Competitive 

William  N.  Maher 


;  ow  that  the  robust  defense 

- 1  market  has  been  permanently 

weakened  by  seismic  geopolitical  shifts, 
system  developers  wanting  to  remain 
alive  and  competitive  must  drastically 
improve  the  quality  of  their  products, 
and  find  ways  to  design  and  build 
them  faster  and  more  efficiently.  En¬ 
gineering  in  particular  must  improve 
its  competitiveness  by  promoting  team¬ 
work,  concurrent  processes  and  total 
quality  management.  In  this  paper,  I 
will  discuss  how  focusing  on  team¬ 
work,  concurrent  processes,  and  quality 
can  be  facilitated  by  structuring  all 
work  according  to  the  product  con¬ 
cept  of  MIL-STD-88 1 B,  and  explicitly 
incorporating  in  the  work  breakdown 


structures  (WBS)  a  DoD-STD-2 167A- 
derived  process.  The  key  is  to  struc¬ 
ture  the  work  of  engineering  to  pro¬ 
mote  quality  in  the  engineering  process 
and  by  extension  into  the  system  be¬ 
ing  developed. 

Integrating  work  organization  based 
on  MIL-STD-88  IB  with  the  workflow 
decreed  by  DoD-STD-2 167A  can  help 
bring  about  desired  changes.  Many 
defense  contractors  have  tended  to 
misconstrue  88 1 B  by  applying  its  work 
organizing  techniques  to  the  perform¬ 
ing  department  rather  than  to  the  sys¬ 
tem  being  developed.  The  resulting 
departmental  work  breakdown  struc¬ 
tures  have  assumed  rather  than  ex- 


FIGURE  1 .  Organizational  Orientation  or 
incomplete  Product  Decomposition 


Cl  =  complex  or  configuration  item 
CSCI  =  computer  software  configuration  item 
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FIGURE  2.  Organization/Discipline  Coordination  or 
Inappropriate  Delegations 
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Frequently  the  breadth  of  disciplines  and  the  number  of  products  being 
worked  make  for  an  impossible  coordination  task  for  the  engineering 
project  manager.  More  effective  delegation  and  coordination  are  required. 


plicitly  specified  2 167A’s  workflow  for 
lower-level  products  like  printed  wir¬ 
ing  assemblies  (PWA)  and  software 
components. 

Emphasizing  the 
Organization  Doesn’t  Work 

Typically,  engineering  decomposes 
a  system  into  subsystems  which  are, 
in  turn,  decomposed  into  hardware 
configuration  items  (Hardware  CIs) 
and  computer  software  configuration 
items  (CSCIs).  Each  subsystem  and 
Cl  contains  lower-level  products  that 
go  through  a  development  process  con¬ 
sisting  of  requirements  analysis,  de¬ 
sign,  build  and  test.  Historically,  at 
this  point  system  decomposition  and 


work  structuring  (to  say  nothing  of 
cost  accounting)  shifts  from  the  ar¬ 
chitecture,  or  system  products,  to  the 
tasks  performed  by  various  engineer¬ 


ing  disciplines  developing  the  prod¬ 
ucts.  This  shift,  depicted  in  the  lower 
half  of  Figure  1,  has  at  least  three 
adverse  consequences: 


— It  fails  to  define  explicitly  the 
lower-level  hardware  and  software 
products  needing  requirements  analy¬ 
sis,  design,  build  and  test.  Too  often, 
the  engineering  project  manager  is 
forced  to  make  this  process  happen. 

—It  creates  a  “stovepiped”  rather 
than  a  team  approach,  resulting  in 
inefficiency  and  ineffectiveness  in  the 
engineering  process  and,  ultimately, 
degrades  the  quality  of  product.  Fig¬ 
ure  2  shows  the  work  defined  in  terms 
of  stovepiped  disciplines  or  depart¬ 
ments.  The  engineering  project  man¬ 
ager  is  directed  to  achieve  a  team 
effort  by  coordinating  these  disciplines 
or,  worse,  it  is  assumed  the  disci¬ 
plines  will  communicate  and  coordi¬ 
nate  themselves.  When  the  sco;)e  of 
coordination  is  large  in  terms  of  disci¬ 
plines  and  multidisciplinary  tasks,  del¬ 
egating  responsibility  t  j  one  person 
is  inappropriate  and  risky.  Further¬ 
more,  expecting  individual  disciplines 
to  coordinate  themselves  is  unrealis¬ 
tic  because  their  focus  is  too  narrow; 
each  concentrates  on  a  single  require¬ 
ment  rather  than  on  the  complete  set 
of  requirements.  In  effect,  inappro¬ 
priate  delegations  fail  to  exploit  the 
real  expertise  in  such  major  engineer¬ 
ing  functions  as  systems  for  systems 
products,  software  for  software  prod¬ 
ucts,  and  equipment  for  equipment 
products. 
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FIGURE  3.  Product  Orientation  or  Complete 
Product  Decomposition 
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PWAs  =  Printed  Wiring  Assemulies 
*CSC  =  Computer  Software  Components 


— It  results  in  poor  processes — 
stovepiped  functions,  serial  activities 
with  “over-the-wall”  handoffs,  and 
confusion  of  roles  and  responsibili¬ 
ties.  Further,  it  obstructs  helpful  work 
and  process  styles  like  multifunction, 
concurrent,  and  project-focused  pro¬ 
cesses,  teamwork,  and  clear  delega¬ 
tions  of  responsibility,  all  of  which 
must  be  encouraged  if  performance 
objectives  are  to  be  met  expeditiously 
and  efficiently. 

Shifting  Emphasis  Product 

How  do  you  shift  work  orientation 
to  lower-level  products  and  what,  if 
anything,  does  it  change?  Figure  3 
shows  decomposition  of  a  system  into 
hardware  and  software  CIs  and  then 
into  the  lower-level  hardware  and  soft¬ 
ware  products  of  those  CIs.  Each 
product  needs  a  requirements  analy¬ 
sis,  design,  build  and  test  process 
multifunction  and  multidepartment 
team  processes.  When  engineering 


Product  Product 

Team  Team 

1  Y 


decomposes  a  system  to  structure  its 
work  in  accordance  with  88 IB,  the 
work  breakdown  structure  consists 
entirely  of  products  instead  of  organi¬ 
zations,  which  is  truer  to  the  letter 
and  spirit  of  88 IB.  By  taking  this 
approach,  engineering  becomes  prod¬ 
uct-oriented  rather  than  department- 
oriented.  This  has  three  major  ad¬ 
vantages. 

—It  explicitly  acknowledges  the 
complexity  of  lower-level  products  and 
implicitly  acknowledges  the  need  for 
requirements  analysis,  design,  build 
and  test  for  each  o  e. 

— It  promotes  concurrent  engineer¬ 
ing  by  focusing  attention  where  it  ought 
to  be  focused — on  designing  the  prod¬ 
uct  rather  than  on  individual  tasks 
performed  by  the  department. 

— It  favors  a  team  approach  be¬ 
cause  it  defines  cost  accounts  by  prod¬ 
uct  rather  than  organization.  This 


Product  Product 

Team  Team 

Y+1  Y  +  2 


makes  team  leaders  responsible  for 
the  quality  of  their  respective  prod¬ 
ucts,  as  opposed  to  the  engineering 
project  manager,  who  then  delegates 
responsibilities  to  team  leaders.  They, 
in  turn,  coordinate  disciplines,  as 
shown  in  Figure  4.  To  put  it  another 
way,  the  engineering  project  manager 
coordinates  teams  rather  than  disci¬ 
plines,  and  management  interfaces  are 
between  the  engineering  project  man¬ 
ager  and  leaders  of  multidiscipline 
teams.  The  flowdown  of  responsibil¬ 
ity  follows  the  hierarchy  of  the  devel¬ 
oped  system,  as  shown  in  Figure  5, 
instead  of  the  organization  chart.  In 
this  example,  responsibility  for  soft¬ 
ware  and  equipment  engineering  for 
software  and  equipment  correctly  flows 
through  systems  engineering.  To  dem¬ 
onstrate  advantages  of  product  orien¬ 
tation  ,  consider  the  systems  engineer¬ 
ing  function.  Difficulties  often  are 
attributed  to  emergence  of  individual 
engineering  specialties  and  obstacles 
they  pose  to  coordination,  integra¬ 
tion  and  teamwork  throughout  the 
development  process.  Product  orien¬ 
tation  helps  systems  engineering  team 
(or  product)  leaders  focus  on  inte¬ 
grating  all  the  specialties;  system  prod¬ 
uct  leaders  have  clear  responsibilility 
to  coordinate  and  delegate  the  work 
to  various  specialties  involved  in  cre¬ 
ating  the  system  products. 

— It  clarifies  goals  and  roles,  sub¬ 
stitutes  product  goals  for  departmen¬ 
tal  or  discipline  goals,  and  replaces 
failure-prone  with  success-oriented 
styles  of  working. 

Phased  Product  Orientation 

To  make  explicit  the  requirements 
analysis,  design,  build  and  test  pro¬ 
cesses  for  lower-level  system  prod¬ 
ucts,  engineering  must  take  product 
orientation  a  step  further.  It  must 
divide  systems,  hardware,  and  soft¬ 
ware  products  along  the  lines  of  the 
subphases  of  a  2167A-derived  pro¬ 
cess  for  engineering  and  manufactur¬ 
ing  development  (EMD),  which  is  the 
same  as  full-scale  development.  This 
is  another  way  of  saying  engineering 


FIGURE  4.  Team/Product  Coordination  of  Effective 
Delegation 
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FIGURE  5.  Hierarchal  Team  Coordination 
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become  the  responsibility  of  another 
internal  function  for  the  activities  of 
the  next  phase  of  the  project  process. 
For  example,  the  build-to-design 
Printed  Wiring  Assembly  (PWA)  prod¬ 
uct  goes  from  equipment  engineering 
to  manufacturing.  Consequently,  the 
phased  product  orientation  allows  in¬ 
ternal  vendors  to  satisfy  needs  of  in¬ 
ternal  customers.  The  internal  ven¬ 
dor,  in  this  case  equipment  engineering, 
must  include  on  the  team  its  internal 
customer,  manufacturing.  The  qual¬ 
ity  implications  are  significant.  Satis¬ 
fying  needs  of  internal  customers  goes 
a  long  way  toward  achieving  world- 
class  quality  products  for  external 
customers. 


must  embed  activities  of  the  2167A 
process  into  the  work  breakdown 
structure. 

The  products  of  the  881 B  WBS  go 
through  a  multiphase  sequence  of 
activities  in  accordance  with  2167A, 
during  which  they  evolve  from  one 
appearance  to  another:  each  phase’s 
product  feeds  the  next  phase  as  an 
input  and,  during  each  phase,  spe¬ 
cific  activities  cause  the  transition  from 
inputs  to  outputs.  Figure  6  illustrates 
that  emphasizing  product  instead  of 
procedure  in  any  phase  is  equivalent 
to  emphasizing  outputs  rather  than 
means  of  getting  those  outputs.  In 
other  words,  product  orientation  em¬ 
phasizes  results  rather  than  the  means 
for  getting  those  results.  Outputs  and 
inputs  outside  the  box  in  Figure  6  are 
emphasized  rather  than  the  proce¬ 
dures  inside  the  box.  While  input/ 
output  values  provide  stable  planning 
parameters,  the  means  to  achieve  them 
may  be  changed  and  improved. 

Figure  7  shows  the  phases  of  a 
sequential  or  waterfall  DOD-STD- 
2167A-derived  development  process 
for  systems,  hardware  and  software. 
Figure  8  shows  that  combining  2 167A 
with  88 IB  results  in  multiple  phases 
for  each  product,  creating  a  dynamic 
WBS.  In  this  dynamic  WBS  the  front- 
end  system  design,  system  design 
implementation,  and  system  integra¬ 


tion  and  test  process  for  subsystems 
are  now  explicit  rather  than  buried 
within  a  static  WBS.  In  addition,  the 
requirements,  design,  build,  and  test 
process  for  hardware  and  software  CIs 
and  their  lower-level  products  are 
also  explicit.  This  dynamic  WBS  es¬ 
tablishes: 

— A  project  work  environment  for 
applying  internal  vendor/customer 
concepts 

— Continuously  improvable  yet 
“constant”  processes 

— Statistical  process  control  of  en¬ 
gineering  design  processes 


Catch  22.  Flow  to  continually  im¬ 
prove  engineering  processes,  yet  re¬ 
tain  a  basic  stability,  is  the  “Catch 
22”  we  confront  today.  Although  com¬ 
ponents  of  a  product  in  each  of  its 
phases  are  the  same,  the  procedures 
by  which  they  are  assembled  may  be 
continuously  improved.  For  example, 
the  build-to-design  phase  of  a  PWA 
contains  a  stable  set  of  components: 
printed  wire  layouts,  drill  tapes,  auto 
insertion  tapes,  assembly  design,  etc. 
The  procedures  for  generating  these 
components  can  be  improved  by  in¬ 
troducing  computer-aided  techniques, 
resulting  in  stability  of  the  workflow 
along  with  continuous  improvement 
of  procedures. 


— Project  cost  estimates  based  on 
products  being  developed. 

Internal  Vendor  Must  Satisfy  Inter¬ 
nal  Customers  First.  Products  often 


Applying  Statistical  Process  Control 
to  Engineering  Design.  Given  the  sta¬ 
bility  of  product  inputs  and  outputs 
in  each  phase,  it  is  possible  to  sched¬ 
ule  a  sequence  of  inputs  and  outputs 


FIGURE  6.  Phased  Products  and  Input/Output 
Emphasis 
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for  the  engineering  design  process. 
Variability  in  the  value  of  these  com¬ 
ponents,  such  as  an  incomplete  drill- 
tape  for  a  PWA,  is  a  deviation  in  the 
process  which  degrades  quality.  En¬ 
gineering,  like  manufacturing,  can  strive 
to  control  variations  in  its  design  and 
development  process  and  thereby 
achieve  greater  quality. 

Estimating  Project  Cost  by  Product 
Rather  than  Engineering  Discipline. 
Phased-product  orientation  opens  a 


way  to  control  variability  in  the  esti¬ 
mating  process  and  sets  the  stage  for 
estimating  engineering  costs  according 
to  the  products  required  to  build  the 
system  and  the  phases  of  the  process, 
rather  than  according  to  engineering 
disciplines  or  departments  that  will 
do  the  work.  On  ensuing  projects, 
phased-product  cost  accounts  permit 
collecting  historical  cost  data  for 
phased-product  tasks.  These  may  be 
used  to  estimate  new  projects  cost 
and  set  continuous  improvement  goals. 


A  significant  step  affecting  engi¬ 
neering  performance  is  defining  prod¬ 
ucts  that  will  make  up  the  system.  A 
good  many  engineering  shortfalls  oc¬ 
cur  when  the  number  of  products  in¬ 
creases  beyond  what  was  estimated 
during  the  proposal  stage.  Phased- 
product  orientation  allows  these  varia¬ 
tions  to  be  tracked  and  controlled. 

Conclusion 

In  conclusion,  we  see  that  inte¬ 
grating  88 IB  and  2167A  is  the  route 
to  better  teamwork,  concurrent  rather 
than  serial  engineering  workflows,  and 
improved  product  quality  for  the  lower- 
level  products  and,  by  extension,  the 
entire  system  being  developed.  The 
best  way  to  implement  this  integra¬ 
tion  is  by  shifting  the  emphasis  from 
the  departments  performing  the  work 
to  the  system  and  its  products. 
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A  MAJOR  ROLE 


MANUFACTURING 

NOTES 

Tooling 

William  T.  Motley 


ooling  includes  devices  like  cut- 

- ters.  jigs,  fixtures,  templates 

and  worker  aids  that  are  required  to 
form,  shape,  fabricate,  assemble,  hold, 
move  or  handle  prime  equipment  or 
any  part  of  it.  Tooling  is  used  to 
repeatedly  reproduce  components 
under  production  conditions.  Tool¬ 
ing  has  impacts  on  cost,  quality,  pro¬ 
duction  rate  and  product  uniformity. 
Tooling  plays  a  major  role  in  produc¬ 
ing  products  made  out  of  metal  or 
composites. 

Accurate  tooling  results  in  the  in¬ 
terchangeability  of  parts.  Attaining 
uniform  product  (minimum  variation 
from  a  dimensional  specification)  is 
one  of  the  primary  purposes  of  tool¬ 
ing.  Dimensional  accuracy  and  rigid¬ 
ity  of  clamping  are  the  prime  require¬ 
ments  of  good  tooling.  In  addition  to 
interchangeability,  tooling  also  is  used 
by  workers  to  make  their  work  easier 
and  faster  with  less  chance  of  error. 

Tooling  can  be  broken  down  into 
four  broad  areas: 

— Cutting  Tools  (perishable):  used 
to  machine  detail  parts  to  shape  and 
to  generate  holes.  Mills,  drill  bits  and 
reamers  are  examples. 


Mr.  Motley  is  the  chair  of  the  Manu¬ 
facturing  Management  Department, 
Defense  Systems  Management  College. 


—Machine  Fixtures:  hold  detail 
parts  in  position  while  processing  op¬ 
erations  take  place.  Drill  fixtures  and 
welding  fixtures  are  examples. 

— Detail  Part  Tools:  fabricate  parts 
from  raw  stock  or  continue  the  pro¬ 
cessing  of  parts  that  were  processed 
on  other  detail  part  tools.  Lay-up 
tools  for  composite  structures  are  an 


example  of  this  type  of  tooling.  Tem¬ 
plates  and  casting  molds  also  fall  into 
this  category. 

— Assembly  Tools:  assembly  tools 
are  usually  the  largest  of  all  tools  and 
frequently  the  most  complex.  When 
two  or  more  parts  are  to  be  accurately 
located  and  attached  to  each  other 
an  assembly  tool  usually  is  needed. 
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Aircraft  canopy  assembly  fixture. 

Assembly  tooling  can  be  hundreds  of 
feet  long  and  many  stories  high,  de¬ 
pending  on  how  many  detail  parts 
are  to  be  assembled  together  and  the 
size  of  the  finished  product.  A  wing 
assembly  jig  holds  spars,  ribs,  and 
wing  skins 
relative  to  each 
other  so  they 
may  be  riveted 
together  after 
drilling. 

Good 
Tooling 
Practices 


— Minimize 
set-ups  and 
breakdowns  of 
any  manufac¬ 
turing  process. 
Strive  for  single 
fixture  opera¬ 
tions — chang¬ 
ing  set-up  and 
fixtures  intro¬ 
duces  variabil¬ 
ity  into  the 
manufacturing 
process. 

— Practice 
functional  gag¬ 
ing  and  tool¬ 
ing;  i.e.,  gages 


and  tools  should  create  the  same  physi¬ 
cal  interfaces  and  distortions  on  criti¬ 
cal  surfaces  as  do  the  actual  mating 
components. 

—To  minimize  variability,  gage  and 
inspect  parts  while  in  the  fixture. 

— Prime  contractors  should  provide 
their  subcontractors  and  suppliers  with 
layout  drawings,  detail  drawings  and 
photographs  of  all  critical  manufac¬ 
turing  and  acceptance  tooling.  To 
ensure  uniform  tooling  philosophy  and 
practices,  a  firm  requirement  for  plans, 
reviews,  and  demonstrations  must  be 


in  each  subcontractor’s  statement  of 
work,  and  timely  reviews  of  the 
subcontractor’s  too'ing  efforts  must 
be  made  by  the  prime  contractor. 

— For  minimum  variability,  all  de¬ 
sign,  manufacturing  and  tooling  ac¬ 
tivities  should  be  based  upon  a  Geo¬ 
metric  Dimensioning  and  Tolerancing 
drawing  system.  Such  a  drawing  sys¬ 
tem  bases  its  geometric  datums  upon 
actual  physical  attributes  of  a  com- 


For  minimum 
variability,  all 
design, 

manufacturing  and 
tooling  activities 
should  be  based 
upon  a  Geometric 
Dimensioning  and 
Tolerancing 
drawing  system. 


Canopy  Assembly  fixture. 
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Fixtures  and  jigging  used  in  the  construction  of  submarine  hulls. 


On  a 
typical 

aircraft  contract, 
there  are  as  many 
or  more  tools 
as  there  are 
parts. 


poncnt  rather  than  imaginary  datums 
such  as  centerlines. 

— To  minimize  variability  and  main¬ 
tain  configuration  control,  all  master/ 
gage  tooling  should  be  produced  by 
the  same  source. 

Progriiin  Office  Concerns 

—Tooling  design  and  fabrication 
is  a  complex,  specialized  field.  The 
difficulty,  cost  and  time  requirements 


of  a  major  tooling  effort  should  not  be 
underestimated. 

— Tooling  planning  must  be  initi¬ 
ated  simultaneously  with  the  manu¬ 
facturing  plan. 

—Tooling  must  be  periodically  cali¬ 
brated;  it  is  subject  to  wear  and  mis¬ 
alignment. 

—Tooling  should  be  discussed  at 
technical  design  reviews. 

— Tooling  wears  out:  provisions 
must  be  made  to  finance  the  replace¬ 


ment  of  tooling  during  the  life  of  a 
program. 

— General  tools  planning  guidelines 
need  to  be  established  for  contractor 
investment,  the  level  of  rate  tooling  to 
be  utilized,  and  the  transition  from 
limited  life  to  rate  tooling. 

— Prime  contractors  and  subcon¬ 
tractors  must  have  and  execute  a  tool¬ 
ing  control  plan  that  addresses  tool¬ 
ing  inventory  control,  tooling 
configuration  control  and  tooling  main¬ 
tenance  and  calibration.  On  a  typical 
aircraft  contract,  there  are  as  many  or 
more  tools  as  there  are  parts.  All  of 
these  tools  must  be  cataloged,  num¬ 
bered,  and  stored  and  kept  up-to-date 
as  design  and  manufacturing  changes 
occur.  It  IS  apparent  that  money  can 
be  saved  by  eliminating  unneedeu 
tools. 

— All  tooling  must  be  proved  be¬ 
fore  its  incorporation  ir  lI'.c  manu¬ 
facturing  process.  Tool'  'culdbe 
proved  on  three-dimensional  objects. 

— Prime  contractors  must  maintain 
visibility  into  their  subcontractors’  tool¬ 
ing  control  plans. 

— Using  soft  tooling  during  raie  pro¬ 
duction  increases  process  variability 
and  puts  your  program  at  risk. 
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Fixtures,  and  jigging  used  in  the  construction  of  submarine  hulls. 


Related  Definitions 

— lig-,  a  device  for  locating,  sup¬ 
porting  and  holding  a  workpiece  in  a 
fixed  position  while  guiding  a  tool  to 
the  workpiece. 

— Fixture:  same  as  a  jig  except  it 
cannot  guide  a  tool. 

—Special  Tooling:  all  hardware,  not 
commercially  available,  that  is  required 
to  produce  a  product. 

— Soft  Tooling:  denotes  flexibility 
of  use  rather  than  a  physical  charac¬ 
teristic.  Soft  tooling  typically  is  used 
during  low-rate  production,  is  cheaper 
to  design  and  fabricate,  can  be  modi¬ 
fied  quickly  but  is  not  durable  or  as 
accurate  as  hard  tooling. 

— Hard  Tooling:  denotes  inflexibil¬ 
ity  of  use  rather  than  a  physical  char¬ 
acteristic.  Hard  tooling  typically  is 
used  during  full-rate  production,  usu¬ 
ally  is  very  expensive  to  design  and 
fabricate,  usually  cannot  be  altered 
but  is  very  durable  and  much  more 
accurate  than  soft  tooling. 

— Expandable  Rale  Tooling:  a  tool¬ 
ing  concept  that  tries  to  combine  the 
flexibility  of  soft  tooling  with  the  ac¬ 
curacy  of  hard  tooling;  generally  ap¬ 
plied  to  assembly  tooling.  Basic  con¬ 


cept  consists  of  a  permanent  (hard) 
external  frame  combined  with  tem¬ 
porary  (soft)  locators  that  are  posi¬ 
tioned  with  theodolites.  Frames  can, 
therefore,  be  used  to  assemble  more 
than  one  component. 

—Tool;  a  device  used  for  the  pur¬ 
pose  of  removing  material  from  a 
workpiece  under  controlled  conditions, 
such  as  a  drill  bit. 


Assembly  tooling 
can  be  hundreds  of 
feet  long  and  many 
stories  high, 
depending  on  how 
many  detail  parts 
are  to  be  assembled 
together  and  the 
size  of  the  finished 
product. 
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RESULTS-ORIENTED 
PROGRAM  MANAGEMENT  AS 

A  LEADERSHIP/ 
MANAGEMENT  MODEL 


IS  esults-orientcd  program 

- 1  management  (ROPM)  is  an 

attitude  of  effective  program/project 
managers.  It  mandates  careful  stew¬ 
ardship  of  resources  and  delivering  a 
product  satisfying  the  customer.  The 
ROPM  develops  executive  competen¬ 
cies  in  senior  managers,  challenging 
them  to  mold  organizational  culture 
to  emphasize  long-term  goals  and 
quality,  in  spite  of  the  daily  compet¬ 
ing  and  conflicting  operational  require¬ 
ments. 

When  identifying  effectiveness 
criteria  for  managing  information  sys¬ 
tems,  literature  is  uniformly  consis¬ 
tent.  The  design,  development  and 
fielding  of  an  information  system  is 
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gram  Manager  for  the  Army  Materiel 
Command. 


For  DOD  Information  Systems 
Program  Managers  ^0. 


James  E.  Price 
Mary-Blair  Valentine 

deemed  successful  when  it  satisfies 
user  requirements,  is  produced  within 
budget  and  completed  on  time.  The 
order  of  priority  may  be  changed,  but 
these  criteria  are  universally  accepted 
by  developers  of  information  systems. ' 
These  criteria  comprise  the  founda¬ 
tion  of  results-oriented  program  man¬ 
agement. 

DOD  Program  Management: 
Information  Systems 
Development 

The  Department  of  Defense  is  a 
complex  environment.  Disparate  el¬ 
ements  must  work  independently,  or 
in  close  synchronization,  depending 
on  changing  circumstances.  The  over¬ 
all  mission  of  defending  the  nation’s 
security  is  subdivided  into  Army  mis¬ 
sions.  Navy/Marine  goals  and  Air  Force 
functions.  The  customer  is,  alternately, 
the  soldier  in  the  desert,  American 
taxpayers  and  their  families,  the  Con¬ 
gress.  or  the  global  village. 

The  DOD,  spending  $30  billion 
annually  on  computer  software,  is  the 
largest  producer  of  software  in  the 
world.’  Much  goes  for  embedded  soft- 


supporting  1 

high-tech  mili¬ 
tary  equipment  like  airplanes,  ships, 
tanks  and  communications  instru¬ 
ments  such  as  those  used  in  Opera¬ 
tion  Desert  Storm.  Of  that  figure,  $9 
billion'  is  spent  on  information  sys¬ 
tem  initiatives.^  Multimillion  dollar 
systems  are  common.  In  fact,  the 
DOD  doesn’t  consider  an  informa¬ 
tion  system  large  unless  life-cycle  costs 
top  $100  million. 

Developing  information  systems  has 
unique  features  that  make  it  interest¬ 
ing  to  investigate.  It  involves  large 
PM  teams  and  is  difficult  to  measure 
progress  or  qualify  short  of  comple¬ 
tion.  It  must  be  done  right  the  first 
time.  Historically,  it  is  plagued  with 
high  turnover  of  personnel  and  re¬ 
quires  careful  stewardship  of  taxpayer 
dollars. 

The  program  management  environ¬ 
ment  in  the  Department  of  Defense  is 
similar  to  any  large  bureaucratic 
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organization;  that  is,  except  for  sizes 
of  program  offices  and  the  cost  of 
information  systems.  When  repre¬ 
sentatives  from  user  community’  or¬ 
ganizations  are  considered,  it  is  not 
unusual  for  a  DOD  program  "team" 
to  include  hundreds.  When  private- 
sector  contractors  join  the  team,  num¬ 
bers  can  be  astronomical. 

Consider  this:  One  programmer 
can  be  expected  to  write,  test  and 
deb'ig  2,000  lines  of  computer  code 
in  1  year.  The  number  of  program¬ 
mers  involved  becomes  mind-boggling 
when  you  consider  many  DOD  infor¬ 
mation  systems  contain  several  mil¬ 
lion  lines  of  computer 
code,  pro¬ 
duced 


by  pro- 
grammers 
working  in  geo¬ 
graphically  dispersed 
groups.  One  author 
likened  it  to  publish¬ 
ing  a  37-chapter  novel, 
with  a  different  person 
writing  each  chapter 
from  a  different  coun¬ 
try."  Therefore,  it  is  an 
organizational  environment 
uniquely  suited  to  use  a  tool 
like  ROPM  to  improve  effec¬ 
tiveness. 


How  to  Implement  Results- 
Oriented  Program 
Management 

The  concept  of  results-oriented  pro¬ 
gram  management  keeps  program 
managers  focused  on  the  big  picture. 
An  attitude  component  connects  this 
concept  with  organizational  culture, 
and  its  goal  is  to  meet  customer/ 
constituent  needs.  It  prevents  pro¬ 
gram  managers  Irom  getting  lost  in 
day-to-day  details.  The  problem  is  that 
senior  management  must  imbed  this 
results-oriented  attitude  into  organi¬ 
zational  culture.  This  requires  sea¬ 
soned  management  skills.  It  raises 
the  question;  What,  specifically,  are 
attitudes,  behaviors  and  competen¬ 
cies  that  make  a  results-oriented  pro¬ 
gram  manager? 

Profile  of  Results-Oriented 
Program  Manager — ^ABCs 

An  extensive  content  analysis  of 
effective  management  criteria,  with  our 
empirical  research,  surfaced  attitudes, 
behaviors,  and  competencies  used  by 
results-oriented  program  managers.' 
The  criteria  provide  the  ABCs  of  an 
effective  results-oriented  program 
manager  as  described  below. 

— Successful  program  managers 
have  a  sense  of  ownership  in  their 
programs,  believe  in  the  mis¬ 
sion  and  can  translate 


team  with  written  and  oral  communi¬ 
cation,  and  by  example. 

— They  maintain  an  efficiency  ori¬ 
entation,  and  develop  program-office 
procedures  to  ensure  resources  en¬ 
trusted  to  them  are  used  wisely.  They 
organize  the  program  office  to  opti¬ 
mize  workers’  contributions  and  track 
task  accomplishment  and  milestones 
toward  program  completion.  They 
create  an  environment  with  a  focus 
on  excellence  and  results-oriented  per¬ 
formance. 

— Effective  managers  are  oriented 
to  action  and  are  concerned  with  im¬ 
pact.  Looking  beyond  the  program 
office,  the  results-oriented  program 
manager  is  aggressive  and  assertive 
in  influence  within  the  tridimensional 
environment.  Organization  reputation 
and  the  prudent  use  of  power  are  key 
concerns. 

— They  use  strategic  influence  and 
fondness  for  proactivity  to  make  things 
happen.  With  a  firm  grip  on  overall 
program  strategy  and  goals,  they  con¬ 
tinually  gather  information,  introduce 
change,  prevent  mishaps,  and  moni¬ 
tor  performance,  budget,  and  timelines 
for  potential  glitches.  Ultimately,  they 
must  accept  blame  for  program  failure 
or  share  praise  for  program  success — 
both  require  hands-on,  proactive, 
effective  management. 
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— Rcsults-orientcd  program  man¬ 
agers  radiate  self-confidence  and  will 
take  the  initiative  to  ensure  program 
success. 

— Successful  program  managers  can 
conceptualize  goals  that  must  be  met 
at  the  end  of  the  program.  Using 
innovation  and  creativity,  the 
effective  program 
man-  insight 

regarding  goals,  their  de¬ 
velopment,  and  ultimate 

attainment.  Using  induc¬ 

tive  reasoning  the  pro¬ 
gram  manager  analyzes 
and  describes  patterns, 
cycles  and  relationships.  The 
PM  develops  concepts  and  themes 
to  guide  managerial  processes,  trans¬ 
mitting  them  to  employees  and  stake¬ 
holders  by  appropriate  models,  meta¬ 
phors,  analogies,  etc, 

— They  use  deductive  reasoning  to 
diagnose  or  interpret  events  occur¬ 
ring  along  the  way  to  program  comple¬ 
tion.  Systematic  thought  is  required 
to  analyze  key  situations  and  keep 
the  program  on  track.  Critical  inquiry 
keeps  the  program  from  becoming  stag¬ 
nant  or  irrelevant  to  changing  needs 
and  fluctuating  demands. 


The 
change 
must  be 
directed  from 
the  top  and 
embodied  in 
attitudes, 
behaviors  and 
competencies  of 
the  program 
manager  and, 
in  many  cases, 
project 
managers. 


to  influence  key  players  in  the  tridi¬ 
mensional  environment  and  in  the 
program  outcome.  The  PM  is  a  role 
model  for  employees,  advocate  for  the 
program,  and  negotiator  for,  and  stew¬ 
ard  of,  required  resources. 


for  performance  targeted  toward  pro¬ 
gram  goal  attainment.  The  PM  must 
instill  vision  on  the  big  picture  so  that 
each  employee  knows  how  critical  each 
role  is  in  the  program's  success.  In 
this  way,  everx'one  may  feel  owner¬ 
ship  in  the  program. 

— The  results-oriented  program 
manager  described  is  a  change  agent. 
Implementation  of  results-oriented 
program  management  requires  an  at- 
titudinal  change  focusing  everyone  on 
the  big  picture.  Why  are  we  here? 
The  answer  is:  To  produce  an  infor¬ 
mation  system  meeting  user  require¬ 
ments,  within  budget  and  on  time. 
Short-range  activities  should  be 
planned  and  executed  with  this  ques¬ 
tion  in  mind:  How  will  action  today 
impact  on  our  long-term  goal? 

It  is  as  change  agents  that  results- 
oriented  program  managers  have  the 
greatest  impact  on  the  organization. 
If  the  organization  is  to  adopt  atti¬ 
tudes,  behaviors  and  competencies 
to  meet  customer  needs,  there  must 
be  change.  The  change  must  be  di¬ 
rected  from  the  top  and  embodied  in 
attitudes,  behaviors  and  competen¬ 
cies  of  the  program  manager  and,  in 
many  cases,  project  managers. 


— Effective  managers  possess  po¬ 
litical  awareness  and  know  how  to 
use  socialized  power  wisely.  The  pro¬ 
gram  office  functions  in  a  highly  po¬ 
liticized  environment  in  which  the  ef¬ 
fective  program  manager  must  establish 
and  maintain  operational  networks 
to  obtain  cooperation  and  coalescence 
on  program  goals.  The  program  man¬ 
ager  of  a  major  program  has  the  power 


— They  are  managers  of  group  pro¬ 
cesses.  Major  programs  cannot  be  com¬ 
pleted  successfully  without  a  smoothly 
functioning  team.  The  program  man¬ 
ager  develops  relationships  at  all  lev¬ 
els  of  the  tridimensional  environment, 
but  is  particularly  concerned  with  en¬ 
suring  the  program  team  is  selected, 
molded,  guided  and  rewarded  for  col¬ 
laborative,  facilitative  teamwork  and 


Results-oriented  Program 
Management  As  a  Leadership/ 
Management  Model 

The  bottom  line  is  this:  If  an  orga¬ 
nization  is  to  change,  in  this  case  to 
infuse  itself  with  an  emphasis  on  qual¬ 
ity  and  an  orientation  toward  results, 
the  existing  organization  culture  must 
be  modified.  If  employees  are  to  re¬ 
spond.  new  culture  and  new  vision 
must  be  presented  in  a  way  that  en¬ 
ables  adapting  personal  goals.  Em¬ 
ployees'  attitudes  must  be  molded  to 
personally  accept  organizational  stra¬ 
tegic  goals  to  complete  an  informa¬ 
tion  system  meeting  user  requirements, 
within  budget  and  on  time. 

Lewin’s  change  model  is  an  effec¬ 
tive  way  to  look  at  this  process.  For 
the  new  vision  to  replace  current  re- 


FIGURE  1 .  Why  We  Need  ROPM 


/r 


99.9  PERCENT  SUPPLIERS  PROVIDE: 

1 .  20,000  incorrectly  filled  prescriptions  annually 

2.  Unsafe  drinking  water  one  hour  a  month 

3.  No  electricity,  water,  or  heat  for  8.6  hours  every  month 

4.  500  incorrectly  performed  surgical  procedures  every  week 

5.  2  long  (or  short)  landings  a  day  at  O'Hare  (also  LAX,  NY,  Atlanta,  etc.) 

6.  2,000  pieces  of  mail  lost  every  hour 


Source 


Unknow^^ 
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FIGURE  2.  Barriers  to 
Change 


ATTITUDINAL  BARRIERS 
We've  Never  Done  It  That  Way 
We’re  Not  Ready  For  That 
We’re  Doing  OK  Without  It 
We've  Tried  It  Before 
It  Costs  Too  Much 
That’s  Not  Our  Job 
It’s  Not  Practical 

CULTURAL  BARRIERS 
Lack  of  Vision 

Lack  of  Understanding/Belief 
Environment  of  Low  Risk-Taking 

SOCIAL  BARRIERS 
Communication 

ORGANIZATIONAL  BARRIERS 
Lack  of  Management  Support 
Poor  Planning 


PSYCHOLOGICAL  BARRIERS 
Track  Record  of  Resistance 


ality,  old  ways  must  be  gradually  elimi¬ 
nated  (unfrozen)  and  replaced  with 
the  new  (changing).  Employees  must 
participate  in  the  change  process.  If 
properly  prepared  for  upcoming 
changes  with  clear  rationale,  new  be¬ 
haviors  will  become  internalized  (re¬ 
frozen)  easier  than  if  sweeping  change 
is  mandated  from  the  top  with  no 
explanation  to,  preparation  with,  or 
participation  from  those  affected.** 

Molding  Organization 
Culture 

Results-oriented  program  manage¬ 
ment  encourages  an  organization-wide 
attitudinal  change,  which  requires  a 
substantial  effort  spearheaded  by  se¬ 
nior  management.  An  organization’s 
culture  influences  its  strategy,  struc¬ 
ture,  operating  procedures  and  inter¬ 
personal  relationships.  Program  man¬ 
agers  need  to  mold  an  organizational 
culture  supporting  their  views  of  how 


team  members  should  perceive,  pon¬ 
der  and  resolve  problems. 

Structural  changes  must  be  made 
within  the  organization.  For  example: 
Lines  of  authority,  span  of  control, 
division  of  labor,  organizational  poli¬ 
cies  and  procedures,  functional  de¬ 
partment  relationships,  communica¬ 
tions,  and  control  of  human  resources 
probably  will  be  modified  to  create 
an  organizational  structure  promot¬ 
ing  a  culture  supportive  of  senior 
management’s  long-term  vision. 

Corporations  feel  the  need  to  match 
lapanese  quality  to  stay  competitive. 
The  Department  of  Defense  must  en¬ 
sure  prudent  use  of  taxpayer  dollars. 
But,  there  are  human  concerns  for 
having  quality  pervade  the  way  we 
work.  Figure  1,  lists  the  service  we 
may  expect  if  settling  for  99.9  percent 
quality.  One-tenth  of  one  percent 
makes  a  difference! 

In  the  information-systems  arena, 
customer  needs  are  not  met  if  there 
are  too  many  lines  of  faulty  code  or  if 
debugging  is  a  longer  and  costlier  pro¬ 
cess  than  the  development  itself.  In 
the  Department  of  Defense,  software 
errors  can  mean  the  difference  be¬ 
tween  a  missile  hitting  its  target,  or 
accuracy  of  high-tech  weaponry  on 
which  our  security  relies. 


doing  so.  People  often  are  afraid  of 
the  unknown  and  want  to  retain  the 
status  quo.  Some  barriers  to  change 
(Figure  2)  that  must  be  overcome  be¬ 
fore  implementing  ROPM  can  be  atti¬ 
tudinal.  organizational,  cultural,  so¬ 
cial  or  psychological. 

Other  implementation  obstacles  are 
prevalent  in  the  program  management 
environment  (Figure  3).  Program 
management  organizations  often  are 
in  a  product-development  mode  that 
ends  when  the  objective  is  met.  As¬ 
signed  and  attached  personnel  may 
lack  loyalty  and  commitment  to  goals 
of  the  program  organization,  and  may 
be  rewarded  for  measurable  jjerfor- 
mance  without  regard  to  quality  of 
output. 

Many  changes  affecting  personnel 
are  concerned  with  new  work  settings 
and  groupings.  According  to  Gabor: 

...most  companies  find  they  must 
also  teach  employees  who  for 
years  have  worked  in  functional 
ftefdoms  how  to  operate  in  multi¬ 
disciplinary  teams.  Industry 
desperately  needs  to  foster  team¬ 
work.  The  only  training  or  edu¬ 
cation  on  teamwork  our  people 
receive  in  school  is  on  the  ath¬ 
letic  field.  Teamwork  in  the  class¬ 
room  is  called  cheating.” 


Although  no  one  would  argue  that 
100-percent  quality  is  the  benchmark 
of  success,  imbuing  the  organization 
with  the  desire  to  produce  quality  in¬ 
formation  systems,  on  time  and  within 
budget  and  satisfying  customer  needs, 
is  not  easy.  There  are  hurdles  to 
overcome. 


Implementation  Obstacles  in 
Program  Management 
Environment 

Implementing  ROPM  represents  an 
organizational  change,  and  many 
people  resist  change.  Why?  People 
are  creatures  of  habit  and  need  to  be 
convinced  to  change  before  willingly 


FIGURE  3.  Program 

Management 

Environment 
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4. 

5. 
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Putting  out  daily  fires 
Short-term  focus 
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Preparing  for  next  major 
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This  is  apropos  in  the  matrix  envi¬ 
ronment  of  program  and  project  man¬ 
agement.  The  challenge  of  blending 
assigned  and  attached  personnel  into 
a  smoothly  functioning  team,  in  con¬ 
cert  with  political  and  other  external 
players,  is  a  key  role  for  the  results- 
oriented  program  manager.  In  geo¬ 
graphically  dispersed  organizations, 
it  becomes  more  critical  that  every 
player  in  every  location  ascribe  to  the 
same  attitudes,  behaviors  and  com¬ 
petencies  to  ensure  customer  needs 
are  met. 

ROPM:  A  Model  for  Change 

Program  management  offices  for 
DOD  information  systems  need  re- 
sults-oriented  program  managers.  The 
PM  offices  are  not  insulated  from  the 
need  to  shift  attitudes,  behaviors  and 
competencies  to  those  who  encour¬ 
age  proactive  change,  effectiveness 
and  efficiency.  To  do  this,  the  PM 
officers  must  instill  a  vision  of  suc¬ 
cess  and  a  willingness  to  forego  the 
status  quo.  Rosabeth  Moss  Ranter 
may  have  expressed  it  best  in  her 
book.  The  Change  Masters. 

...the  more  profound,  compre¬ 
hensive,  and  widespread  the 
proposed  change,  the  more  ab¬ 
solute  is  the  need  for  deep  un¬ 
derstanding  and  active  leader¬ 
ship  by  the  top  managers....'® 

Complexity  and  size  of  DOD  infor¬ 
mation  systems  organizations  make 
them  prime  targets  for  the  kinds  of 
results  offered  by  using  results-oriented 
program  management.  The  matrix 
structure  of  the  project  office  is  a  per¬ 
fect  environment  for  ROPM  team¬ 
building. 

It  is  extremely  difficult  for  program 
managers  to  keep  their  spotlights  on 
long-term  goals  with  competing,  and 
often  conflicting,  operational  require¬ 
ments.  Nevertheless,  PMs  must  move 
beyond  the  process  orientation  often 
found  in  bureaucratic  organizations 
and  focus  on  producing  results.  The 
question  is:  Where  do  they  look? 


If  the  management  style  of  organi¬ 
zation  leaders  reflects  a  commitment 
to  results-oriented  program  manage¬ 
ment,  all  personnel  with  that  perspec¬ 
tive  will  perpetuate  the  attitude.  An 
organization  open  to  change  will  have 
no  difficulty  in  continually  improving 
processes  for  the  betterment  of  sup¬ 
pliers  and  customers. 

Results-oriented  program  man¬ 
agement’s  emphasis  on  the  big  pic¬ 
ture  can  only  enhance  inevitability  of 
program  success.  In  the  program- 
management  environment,  results-ori¬ 
ented  program  management  is  a  tool 
suitable  for  beginning  the  process  of 
redirecting  organizational  focus  to 
quality:  that  is,  developing  an  infor¬ 
mation  system  (or  any  product  or  ser¬ 
vice)  that  meets  customer  needs,  within 
budget,  and  on  time. 

The  results-oriented  program  man¬ 
ager  is  the  change  agent  guiding  the 
organization  to  this  new  way  of  doing 
business,  and  to  greater  success  in 
meeting  organizational  goals. 
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MANAGING  CHANGE 


ORGANIZATION 
DEVELOPMENT 

What  Is  It?  How  Can  You  Use  It? 


o 


ne  fact  about  the  business 

- 1  climate  stands  out  from  all 

others.  The  pace  and  effect  of  change 
is  greater  than  ever  before.  New  prod¬ 
ucts,  new  methods  of  doing  business 
and  new  competitors  pose  problems 
that  have  no  precedent.  In  order  to 
meet  today’s  challenges  it  is  essential 
that  organizations  use  their  resources 
in  the  most  effective  ways  possible. 

The  organizational 

development  (OD)  FIGURE  1.  Four-Step 
pr^xess  and  skilled 
OD  practitioners 

are  valuable  tools  ]  I 

in  the  effort  to  re-  ^  Gathering  | 

main  competitive  - 

and  profitable.  / 


The  - 

past  30  to  Evaluation 

35  years  _ 

have  seen  W 

evolution  of  a  new  ^ 
service  and  profes-  \ 
sion  which  is  called  N  I 
organization  devel-  Implen 

opment.  This  ar-  ' - 

tide  provides  a  gen¬ 
eral  overview  of  this  profession  and 
presents  ideas  on  how  the  service  can 
be  used  in  your  program  management 
or  acquisition  organization  to  improve 
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Major  Jim  Wilson,  USA 


your  products  or  services.  After  a 
general  description  and  background 
of  OD,  1  will  “walk  through”  a  typical 
OD  “intervention.” 

Organizational  development  is  a 
systematic  effort  to  improve  an  orga¬ 
nization  based  on  melding  of  organi¬ 
zation  theory  with  behavioral  theory. 
It  depends  on  an  effective  process  of 
gathering  informa- 
■OUrStep  ‘>0"’  interpreting 

that  information 
and  making  plans 
I  from  it,  implement- 

Ihering  ing  those  plans  and 

- 1  V  evaluating  the 

\  implementation  to 
«  determine 

- ^ -  effective- 

Data  Interpretation  ness  This 

S  Action  Plamlno  "s  some- 


Implementation 


times 
known  as  the  four- 
step  process  which 
might  look  like  Fig¬ 
ure  1. 


These  four  steps 
should  be  considered  as  a  never-end¬ 
ing  cycle  because,  as  long  as  the  or¬ 
ganization  exists,  there  are  changes 
happening  that  need  to  be  managed 
effectively.  The  OD  provides  a  method 
for  using  the  process  of  change  to  the 
organization's  benefit. 

Organizations  can  be  seen  as  hav¬ 
ing  two  parts,  a  social  system  and  a 
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technical  system.  The  technical  sys¬ 
tem  is  the  content  of  the  business 
and  is  peculiar  to  each  type  of  busi¬ 
ness.  In  the  building  industry,  for 
example,  the  technical  system  revolves 
around  the  knowledge  skills  and  abili¬ 
ties  to  provide  technical  plans,  pour 
concrete,  bend  metal,  cut  wood,  etc. 
The  social  system  of  an  organization 
is  the  means  by  which  people  inter¬ 
act  to  successfully  implement  the  tech¬ 
nical  system.  The  OD  improves  orga- 
nizations  through  collaborative 
processes  that  focus  on  the  social  sys¬ 
tem  of  the  organization  as  the  means 


of  improving  the  social  and  technical 
systems. 

A  helpful  way  to  examine  the  orga¬ 
nization  is  through  the  use  of  systems 
models.  I  will  discuss  an  example  of 
a  systems  model  later. 

A  second  element  of  the  method  is 
to  understand  the  assumptions  un¬ 
derlying  OD.  Some  of  the  most  im¬ 
portant  are: 

— Groups  of  people  are  the  basic 
building  blocks  of  organizations 


so  working  with  groups  is  the 
primary  way  of  effecting  change. 

— Honest  and  supportive  rela¬ 
tionships  are  critical  to  achieving 
a  high-performing  organization. 

— People  seek  and  are  most  effective 
in  situations  where  they  have  an 
opportunity  to  contribute 
responsibly  to  achieving  goals  and 
are  recognized  and  rewarded  for 
doing  so. 

— Collaboration  and  participation  are 
the  most  effective  ways  to 
implement  change  and  improve 
effectiveness. 

The  third  element  of  the  OD  method 
mentioned  here  is  the  use  of  a  trained 
OD  consultant  or  practitioner.  There 
are  several  roles  that  consultants  typi¬ 
cally  take  in  organizations:  The  ex¬ 
pert  role,  where  the  expert  provides 
direction  about  what  to  do;  the  staff 
role,  where  the  consultant  is  seen  to 
be  an  extension  of  the  existing  staff; 
and  the  collaborative  or  facilitative 
role  where  the  consultant  gathers  in¬ 
formation  and  helps  the  organization 
focus  on  issues  it  decides  are  impor¬ 
tant.  The  OD  consultant  functions  in 
the  collaborative  or  facilitative  role. 
This  will  be  made  clearer  when  we 
“walk  through”  a  typical  OD  “inter¬ 
vention.” 

I  mentioned  one  of  the  ways  to 
examine  the  organization  is  through 
the  use  of  systems  models,  which  serves 
as  a  framework  upxjn  which  data  about 
the  client  company  can  be  structured. 
This  allows  systematic  study  that  helps 
to  understand  the  complex  function¬ 
ing  of  the  system.  1  will  describe  one 
widely  used  model,  the  “six  box”  and 
use  it  in  our  “walk-through”.' 

In  the  six-box  model,  each  box 
represents  a  subsystem  of  the  organi¬ 
zation.  They  are:  purpose,  structure, 
leadership,  relationships,  rewards  and 
helpful  mechanisms  boxes.  Informa¬ 
tion  gathered  about  the  organization 
in  the  data  gathering  or  assessment 
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phase  of  OD  interventions  will  fit  into 
one  or  more  of  these  boxes.  This 
information  is  then  analyzed  using 
organizational  theory  appropriate  to 
each  box.  The  result  is  a  “snapshot” 
of  the  organization  as  it  existed  at 
the  time  data  were  gathered.  This 
information  is  the  basis  for  mak-  ^ 
ing  decisions  about  what  / 
change  is  desir-  J 

able  in  the  or-  - - — — 

g  a  n  i  z  a  t  i  o  n .  Relationships: 

T  u :  o  ^  a  ^  I  How  do  we  manage 
Th  s  model  conflict  among  p^pl. 

could  look  like  with  technologies? 

Figure  2.  _ _ _ 

We  are  now  ready  to  1 
begin  walking  through  a  \ 
typical  OD  process.  The  ^ 

first  step  occurs  when  — ^ - 

someone — the  client — in  Helpful  Ki 

an  organization  decides 

that  an  OD  consultant  technolog 

might  be  of  help  in  some  _ 

way,  contacts  a  consult¬ 
ant  and  sets  up  a  meeting.  The  pur¬ 
pose  of  this  first  meeting  is  for  the 
prospective  client  to  lay  out  the  con¬ 
cerns  that  motivated  calling  a  con¬ 
sultant.  The  consultant  can  be  ex¬ 
pected  to  ask  clarifying  questions  to 
help  focus  the  prospective  client  on 
current  concerns.  At  some  point,  a 
tentative  decision  is  made  by  both 
parties  regarding  desirability  of  work¬ 
ing  together  to  solve  whatever  prob¬ 
lems  may  exist. 

A  prospective  client  could  expect 
several  meetings  with  the  consultant 
to  refine  specifics  and  negotiate  a  con¬ 
tract  that  spells  out  the  specifics  of 
what  is  to  be  done.  Some  issues  that 
might  be  mentioned  are:  objectives 
of  the  project,  means  of  gathering 
information,  who  the  client  is,  kind  of 
information  sought,  any  boundaries 
on  information  sought,  each  person’s 
role  in  the  project,  product  to  be  de¬ 
livered  by  the  consultant,  support  and 
involvement  expected  of  the  client,  a 
time  schedule,  confidentiality  and  ano¬ 
nymity  of  information,  feedback  of 
data  to  the  client  and  other  partici¬ 
pants  in  the  project,  fees  and  pay¬ 
ment  schedules  or  procedures  for  ter- 


FIGURE  2.  Systems 
Model 


Purposes: 

What  business  are 
we  in? 


Relationships: 

Structure: 

How  do  we  manage 

How  do  we  divide 

conflict  among  people? 

Leadership: 

Does  someone  keep 

the  work? 

With  technologies? 

Helpful  Mechanisms: 

Have  we  adequate 

coordinating 

technologies? 


Rewards: 

Do  all  needed  tasks 
have  incentives? 


problems  to  be  solved.  Action  plans 
are  created  by  the  people  responsible 
for  effecting  the  proposed  change,  and 
the  people  who  will  be  affected  by  the 
change.  The  range  of  actions  that 
might  be  taken  can  be  as  broad  as 
efforts  at  large-scale  cultural 
change  and  strategic  planning, 
.  or  as  specific  as  team  build- 
ing  with  one  or 

-  more  work 

teams.  (The 
divide  consultant  Is 

not  responsible 

_  for  implement- 

i  ing  the  changes. 

I  The  organization  is.) 
/  Usually,  there  will  be  a 

J  decision  on  the  method 

-  of  evaluating  the  effects 

caused  by  implementation 

I  tackc  ^  * 

,  of  the  action  plans. 


mlnation,  and  any  restrictions  placed 
on  the  consultant. 

Once  client  and  consultant  reach 
an  agreement  and  sign  a  contract  the 
consultant  will  implement  the  four- 
step  process.  Information  will  be  gath¬ 
ered  by  one  or  more  of  several  meth¬ 
ods  such  as  interviews,  surveys,  and 
study  of  company  records.  The  data 
gathering  objectives  depend  on  ob¬ 
jectives  of  the  project.  TTie  data  gath¬ 
ering  can  be  broad,  covering  many 
aspects  of  the  system,  or  more  nar¬ 
rowly  focused  on  a  specific  system 
part.  The  information  is  organized 
according  to  some  method  such  as 
the  six-box  systems  model  and  ana¬ 
lyzed  by  the  consultant.  In  some 
cases,  the  client  and  consultant  may 
have  decided  to  jointly  analyze  the 
data.  In  any  case,  the  information  is 
presented  to  the  client  in  a  feedback 
meeting. 

Based  on  results  of  the  feedback 
meeting  some  decisions  may  be  made 
regarding  issues  to  be  addressed  or 


_ I  Often,  when  action 

plans  are  implemented, 
ongoing  evaluation  of  the  implemen¬ 
tation  may  dictate  midstream  correc¬ 
tions.  Final  evaluation  of  the  effects 
of  the  implementation  of  action  plans 
will  be  made  as  the  implementation 
is  finished.  This  data  can  then  serve 
as  a  basis  for  further  data  gathering 
and  future  actions.  The  four-step  pro¬ 
cess  provides  a  method  for  continu¬ 
ous  process  improvement,  a  funda¬ 
mental  aspect  of  total  quality 
management. 

The  organization  development  pro¬ 
cess  and  OD  consultants  are  valu¬ 
able  tools  in  the  effort  to  become  more 
competitive  and  profitable.  Leaders 
of  organizations  can  use  the  process 
to  accomplish  many  goals.  To  learn 
more  abut  the  process  feel  free  to  call 
Major  Jim  Wilson  at  the  Defense  Sys¬ 
tems  Management  College,  commer¬ 
cial  (703)  805-3425. 


Endnotes 

1 .  The  six-box  model  was  created  by 
Marvin  Weisboard. 


Progrom  Monoger 


20 


November  -  December  1 992 


1993  ANNUAL  RELIABILITY  and 
MAINTAINABILITY  SYMPOSIUM 


Westin  Peachtree  Plaza  Hotel 
Atlanta,  GA  USA 


January  25-28, 1993 


THEME 

ASSURANCE  TECHNOLOGIES  FOR 
TOMORROW'S  ENVIRONMENT 


Total  Quality  Management 
R&M  Management 
Software  R&M 
R&M  Case  Studies 
Maintainability/Logistics 


•  Reliability  Growth/Testing 

•  Commercial  Reliability 

•  R&M  Tutorials 

•  International  Standards 

•  R&M  with  Decreasing  Budgets 


For  More  Information  Contact; 


AIAA  ASQC 

Rekabtiify  Div 
Eiedronics  Div 


SPONSORING  SOCIETIES 


IEE£  lES  ItE  SAE  SOLE 

Rel^lty 

Society 


R.G.  Schueppert,  Jr. 
Beckman  Instruments,  Inc. 
200  S.  Kraemer  Blvd. 

MS;  W351 

Brea,  CA  92621  USA 
(714)961-3793 
FAX  (714)961-3743 


STATEMENT  REQUIRED  BY  THE  ACT  OF  AUGUST  12,  1970,  SECTION  3685,  TITLE  39,  UNITED 
STATES  CODE.  SHOWING  THE  OWNERSHIP.  MANAGEMENT.  AND  CIRCULATION  OF 

Program  Manager,  published  bimonthly  at  the  Defense  Systems  Management  College,  Fort  Belvoir,  VA 
22060-5426.  Number  of  issues  published  annually:  6.  The  Director  of  Publications  is  Robert  W.  Ball,  Defense 
Systems  Management  College,  RD-P,  Fort  Belvoir,  VA  22060-5426.  The  Managing  Editor  is  Catherine  M.  Clark, 
Defense  Systems  Management  College,  RD-P,  Fort  Belvoir,  VA  22060-5426.  The  publisher  is  the  Defense 
Systems  Management  College,  Fort  Belvoir,  VA  22060-5426. 


The  average  number  of  copies  each  issue  during  the 
preceding  1 2  months: 

A.  Total  number  of  copies  printed  (net  press  run):  13,083 

B.  Paid  and/or  requested  circulation:  1,500 

1 .  Sales  through  dealers  and  carriers,  street  vendors, 
and  counter  sales:  None 

2.  Mail  subscriptions  paid  and/or  requested:  10,000 

C.  Total  paid  and/or  requested  circulation:  1 1 .500 

D.  Free  distribution  by  mail,  carrier,  or  other  means, 
samples,  complimentary,  and  other  free  copies:  1 ,500 

E.  Total  distribution:  13.000 

F.  Copies  not  distributed 

1.  Office  use.  leftover,  unaccounted,  spoiled  after 
printing:  83 

2.  Returns  from  news  agents:  None 

G.  Total  distribution:  13,083 


The  actual  number  copies  of  single  issue  published  near¬ 
est  to  filing  date: 

A.  Total  number  of  copies  printed  (net  press  run):  10,500 

B.  Paid  and/or  requested  circulation:  1 ,500 

1 .  Sales  throught  dealers  and  carriers,  street  vendors, 
and  counter  sales:  None 

2.  Mail  subscriptions  paid  and/or  requested:  7,000 

C.  Total  paid  and/or  requested  circulation:  8,500 

D.  Free  distribution  by  mail,  carrier,  or  other  means, 
samples,  complimentary,  and  other  free  copies:  1 ,500 

E.  Total  distribution:  10,000 

F.  Copies  not  distributed: 

1.  Office  use,  leftover,  unaccounted,  spoiled  after 
printing:  500 

2.  Return  from  news  agents:  None 

G.  Total  distribution:  10,500 


Progrom  Monoger 


21 


November  -  December  1 992 


MISSION  CRITICAL  COMPUTER  RESOURCES 


THE  SOFTWARE 
DEVELOPMENT  PROCESS 

An  Integral  Part  of  Weapon  Systems 


Captain  Jeanne  L.  Murtagh,  USAF 


The  purpose  of  the  hardware  and  software  embedded  in  the  fire  control  system  on  a  fighter 
aircraft  is  to  accept  information  from  the  sensors,  identify  targets,  and  select  and  launch 
weapons  against  these  targets. 


c 

J  !  oftware  is  an  integral  part  of 
—  '  virtually  all  weapon  systems, 
so  it’s  useful  for  anyone  involved  in 
weapon-systems  development  to  un¬ 
derstand  the  software  development 
process.  This  article  covers  the  defi¬ 
nition  of  mission  critical  computer  re¬ 
sources  and  addresses  the  process 
used  to  develop  this  type  of  software. 

Definition  of  Mission  Critical 
Computer  Resources 

What  are  mission  critical  computer 
resources  (MCCR)?  This  includes 
hardware  and  software  critical  to  a 
military  application.  These  resources 
are  usually  "embedded”  in  another 
system.  The  software  in  MCCR  tends 
to  be  harder  to  develop  than  software 
for  other  types  of  applications.  This 
is  primarily  because  most  MCCR  soft¬ 
ware  must  operate  in  “real-time.”  In 
other  words,  there  are  very  rigid  time 
constraints  on  this  type  of  software. 
This  may  become  clearer  with  an 
example. 

The  fire  control  system  on  a  fighter 
aircraft  contains  MCCR.  The  pur¬ 
pose  of  the  hardware  and  software 
embedded  in  this  fire  control  system 
is  to  accept  information  from  the  sen- 
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Acquisition  Course,  3440  Technical 
Training  Squadron,  Lowry  Air  Force 
Base,  Colorado.  She  has  8  years  of 
acquisition  experience  and  holds  an 
M.S.  degree  in  computer  science. 


sors  on  the  aircraft,  identify  targets, 
and  select  and  launch  weapons  against 
these  targets.  Software  in  the  fire 
control  system  must  accept  a  mes¬ 
sage  from  the  fighter’s  radar  stating 
the  identity  and  position  of  the  target. 
If  much  time  elapsed  between  receipt 


of  this  message,  and  selection  and 
launch  of  a  weapon,  the  target’s  posi¬ 
tion  would  probably  have  changed 
enough  to  cause  the  weapon  to  miss 
it.  The  amount  of  time  which  could 
be  allowed  to  elapse  without  causing 
difficulty  would  probably  be  measured 
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in  milliseconds.  Contrast  this  with  a  “Seven,  Plus  FIGURE  1.  Anatomy  of  a  CSCI 
typical  data  processing  example.  It  Or  Minus 
really  should  not  matter  if  it  takes  an  Two,  Rule" 
extra  four  minutes  to  run  this  month’s 
payroll.  Humans 

have  a  limited 

The  development  of  MCCR  soft-  capability  to 
ware  is  governed  by  DOD-STD-2167A.  manage  unre- 
This  standaH  describes  steps  in  the  lated  informa- 
software  de'  jlopment  process,  and  tion.  We  nor- 
the  documentation  and  reviews  and  mally  only 
auditsassociated  with  each  step.  The  remember  and 
standard  can  be  tailored  to  accom-  work  with  seven, 
modate  each  program's  needs.  plus  or  minus 

two,  items  or  is- 
Approach  to  sues  at  a  time. 

Software  When  the  num- 

Development  ber  of  items  you 
need  to  remem- 

Before  we  can  ber  and  work  with — at  one  time —  program — into  smaller,  related  pieces, 
discuss  details  of  exceeds  this  limit,  you  need  to  start  so  we  won’t  exceed  our  capacity  to 
the  software  devel-  “chunking”  (or  grouping)  items  into  manage  the  parts  of  the  problem, 
opment  process,  related  categories.  The  seven,  plus  or 

we  need  to  address  minus  two,  rule  is  based  on  research  Top-Down  Design  Process 
more  general  is-  done  by  George  Miller  at  Harvard 

sues.  Designing  University.  Additional  information  The  top-down  design  process  lets 
large  computer  can  be  found  in  The  Brain  Book,  by  us  do  just  that.  The  basic  idea  is  that 
programs  is  a  dif-  Peter  Russell.  we  start  with  a  very  broad  definition 

ficult  process.  It  of  what  the  computer  program  must 

requires  us  to  This  restriction  on  capacity  to  man-  do,  and  then  progressively  refine  this 
manage  huge  age  unrelated  facts  explains  why  we  definition,  adding  more  details  at  each 

amounts  of  com-  cannot  attack  the  development  of  a  step.  This  very  broad  definition  is 

plicated  informa-  huge  military  computer  program  in  abstract;  it  does  not  contain  detailed 

tion,  and  we  hu-  one  step.  Most  military  computer  information.  As  we  add  details  at 

mans  have  a  programs  (for  example,  the  software  each  step,  ovr  solution  becomes  less 

limited  capacity  to  that  drives  the  flight  control  surfaces  abstract  and  more  concrete;  it  becomes 

dothat.  We’ll  look  in  the  “fly-by-wire”  F-16  )  are  very  progressively  more  specific.  This  lets 

at  the  research  large.  The  minimum  number  of  lines  us  break  a  large  problem  into  several 

basis  for  that  lim-  of  code  (or  individual  instructions)  in  smaller  problems.  Then  we  apply 

ited  capacity  first,  this  type  of  program  is  usually  around  this  same  approach  to  each  of  the 

Then  we’ll  talk  30,000.  If  we  tried  to  tackle  that  smaller  problems,  until  they  get  small 

about  an  approach  project  in  just  one  step,  we  would  enough  that  we  can  retain  enough 

to  software  design  clearly  exceed 
which  helps  us  or-  our  capacity  to 
ganize  all  the  in-  keep  track  of  all 
formation  we  need  pieces  of  infor- 
so  that  we  can  mation  (the  lines 
manage  it.  This  of  code)  and 

approach  involves  how  they  should 

dividing  our  computer  program  into  work  together, 

pieces  small  enough  to  understand. 

We’ll  talk  about  specific  names  for  We  need  to 
each  piece  of  the  computer  program,  somehow  divide 
This  will  provide  you  with  enough  our  problem — 
information  to  understand  details  of  how  to  develop 
the  software  design  process.  the  computer 


FIGURE  2.  An  Analogy 
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FIGURE  3.  Steps  in  the  Software  Development 
Process 


information  to  solve  them.  This  pre¬ 
vents  us  from  violating  the  seven,  plus 
or  minus  two,  rule,  since  we  need  to 
work  on  only  one  of  the  smaller  prob¬ 
lems  at  a  time. 

Anatomy  of  a  CSCI 

Top-down  design  requires  us  to  di¬ 
vide  a  computer  program  into  pro¬ 
gressively  smaller  and  simpler  parts 
as  we  design  the  program.  We  have 
specific  names  for  each  of  these  parts 
(Figure  1). 

Each  entire  computer  program  is 
called  a  computer  software  configu¬ 
ration  item  or  CSCI. 

Each  CSCI  is  divided  into  a  num¬ 
ber  of  computer  software  components 
or  CSCs.  It  is  common  to  have  sev¬ 
eral  levels  of  CSCs  in  the  CSCI. 


The  smallest  entity  in  a  CSCI  is 
called  a  computer  software  unit  or 
CSU.  Programmers  have  many  names 
for  these  entities:  subprograms,  func¬ 
tions,  procedures  or  modules.  We 
often  require  that  no  CSU  contain 
more  than  100  lines  of  code  (or  indi¬ 
vidual  instructions).  This  helps  en¬ 
sure  that  the  CSU  does  not  get  too 
complex  to  understand. 

You  can  draw  an  analogy  between 
writing  a  large  computer  program  .  nd 
writing  a  book.  Organizing  the  entire 
computer  software  configuration  item 
is  similar  to  organizing  the  book.  You 
would  break  the  book  into  chapters; 
the  CSCI  would  be  broken  into  its 
major  computer  software  components. 
The  chapters  in  the  book  might  be 
divided  into  different  sections:  the 
major  CSCs  would  each  be  divided 
into  smaller  CSCa.  Each  section  of 


the  book  would  be  divided  into  para¬ 
graphs;  the  lowest  level  CSCs  would 
be  divided  into  CSUs.  Paragraphs 
comprise  sentences,  which  represent 
one  complete  thought;  CSUs  comprise 
lines  of  code  (LOC),  which  contain 
one  complete  instruction  to  the  com¬ 
puter  (Figure  2). 

Now  that  you  have  a  general  un¬ 
derstanding  of  the  software  develop¬ 
ment  process,  let’s  move  on  to  more 
specific  information. 

The  Software  Development 
Process 

This  section  covers  steps  in  the 
software  development  process.  I’ll 
discuss  what  specifications  are  devel¬ 
oped  during  each  step,  and  talk  about 
software  reviews  and  audits  that  oc¬ 
cur. 

Figure  3  places  steps  in  the  soft¬ 
ware  development  process  on  a  soft¬ 
ware  development  V  (See  Figure  1). 
This  ‘"V”  should  help  you  see  how 
systems  are  designed  and  built. 

Notice  that  the  software  develop¬ 
ment  process  starts  at  a  high  le\  cl  of 
abstraction,  progresses  to  a  very-low 
level  of  abstraction,  and  then  moves 
back  up  the  “abstraction  ladder”  dur¬ 
ing  testing.  This  is  how  we  use  top- 
down  design.  This  helps  us  manage 
the  complexity  of  a  software  develop¬ 
ment  effort.  \Ve  discussed  why  this  is 
important  in  the  last  section. 

Notice,  also,  that  the  software  “V" 
emphasizes  that  software  development 
involves  much  more  than  just  writing 
the  code! 

Let’s  briefly  discuss  what  happens 
in  each  step  of  the  software  develop¬ 
ment  process. 

System  requirements  analysis  and 
design  is  the  first  step  in  the  software 
development  process.  The  software 
team  at  the  contractor’s  site  analyzes 
the  system  specification  to  determine 
whether  software  requirements  are 
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complete  (for  that  level  of  abstrac¬ 
tion)  and  consistent.  Results  of  this 
analysis  are  presented  at  the  System 
Requirements  Review  (SRR).  The  soft¬ 
ware  team  determines  how  many  com¬ 
puter  software  configuration  items  will 
be  required  for  the  system,  and  allo¬ 
cates  the  system’s  software  require¬ 
ments  to  each  of  these  CSC  Is.  This 
will  be  presented  to  the  government 
at  the  System  Design  Review  (SDR). 
Preliminary  software  test  planning  also 
is  started. 

Software  requirements  analysis  is 
the  next  step.  During  this  step  you 
determine  exactly  what  each  CSCl 
will  do.  The  contractor's  software 
team  completes  engineering  require¬ 
ments  for  each  CSCI  and  documents 
these  in  the  software  requirements 
specifications  (SRS).  A  Software  Speci¬ 
fication  Review  (SSR)  is  held  to  re¬ 
view  the  SRS.  The  contractor’s  soft¬ 
ware  team  analyzes  requirements  for 
each  CSCI  external  interface.  These 
requirements  are  documented  in  the 
interface  requirements  specifications 
(IRS).  A  complete  list  of  qualification 
requirements  for  each  CSCI  is  pre¬ 
pared  during  this  step.  This  is  in¬ 
cluded  in  the  SRS  for  each  CSCI. 

It  is  critical  that  the  software  re¬ 
quirements  analysis  step  be  done  well! 
If  you  don’t  know  what  you  are  trying 
to  build,  it  will  be  impossible  to  deter¬ 
mine  how  to  build  it.  We  sometimes 
are  tempted  to  accept  software  re¬ 
quirements  specifications  that  are  not 
adequate  in  order  to  stay  on  sched¬ 
ule.  We  must  guard  against  this.  Soft¬ 
ware  requirements  specifications  are 
the  foundation  for  the  entire  software 
development  effort.  If  we  accept  in¬ 
complete  or  inconsistent  requirements 
specifications,  we  will  maintain  the 
on-schedule  illusion  (since  documents 
will  be  authenticated  on  time),  but 
we  will  not  actually  be  on  schedule 
(since  there  are  problems  that  we  will 
have  to  manage  sometime)!  Eventu¬ 
ally,  we  will  hit  a  step  in  the  software 
development  process  (for  example, 
CSCI  testing)  which  requires  us  to 
actually  make  the  software  work.  At 


this  point,  we  have  to  fix  problems. 
Here’s  the  catch:  We  now  have  more 
than  our  original  problem  to  manage. 
Those  requirements  errors  have  been 
propagated  into  the  designs,  source 
code  and  test  plans.  We  will  have  to 
fix  these,  in  addition  to  the  original 
problem.  Thus,  the  result  of  failing  to 
admit  that  the  schedule  needed  to 
slip  a  small  amount  in  order  to  en¬ 
sure  that  requirements  were  adequate 
is  a  much  larger  schedule  slip  later  in 
the  program. 

Preliminary  design  is  the  next  step. 
You  have  determined  what  you  want 
to  build;  now  you  must  determine 
how  to  build  it.  The  contractor’s  soft¬ 
ware  team  develops  a  preliminary  de¬ 
sign  for  each  CSCI.  This  is  accom¬ 
plished  by  decomposing  the  CSCI  into 
computer  software  components,  and 
determining  what  requirements  each 
CSC  will  incorporate.  This  prelimi¬ 
nary  design  is  documented  in  the  soft¬ 
ware  design  document  (SDD)  for  each 
CSCI.  The  preliminary  design  for  each 
CSCTs  external  interface  is  developed 
in  this  step.  This  is  documented  in 
the  interface  design  document  (IDD) 
for  each  CSCI  interface.  An  impor¬ 
tant  part  of  this  is  ensuring  that  all 
requirements  from  the  SRS  and  the 
IRS  are  addressed  in  this  design.  This 
is  called  traceability  of  requirements. 


Formal  qualification  tests  for  this  CSCI 
are  also  defined  now.  These  are  docu¬ 
mented  in  the  software  test  plan  (STP). 
The  preliminary  design  is  reviewed  at 
a  software  preliminary  design  review 
(PDR). 

Detailed  design  follows  preliminary 
design.  The  detailed  design  for  each 
CSCI  is  developed  now.  This  is  ac¬ 
complished  by  allocating  requirements 
from  each  CSC  to  the  computer  soft¬ 
ware  units  which  will  comprise  that 
CSC,  and  by  establishing  the  design 
requirements  for  each  CSU.  The  soft¬ 
ware  design  document  is  expanded 
to  include  this  information.  Require¬ 
ments  from  the  IRS  also  are  refined 
into  detailed  design  information.  This 
is  added  to  each  interface  design  docu¬ 
ment.  Formal  qualification  test  plan¬ 
ning  continues.  Specific  test  cases 
are  developed,  based  on  the  informa¬ 
tion  in  the  software  test  plan,  and  this 
information  is  documented  in  the  soft¬ 
ware  test  description  (STD).  The  soft¬ 
ware  Critical  Design  Review  is  con¬ 
ducted.  This  will  result  in  approval  to 
start  writing  code. 

Code  development  and  unit  test  is 
the  next  step.  The  contractor  drafts 
the  software  product  specification  (SPS) 
and  writes  the  code  for  each  CSU. 
The  code  normally  will  be  reviewed 


FIGURE  4.  The  Software  “V” 
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at  a  code  walkthrough  before  it  is 
entered  into  the  computer.  During 
this  step,  the  code  is  tested  at  the 
CSU  level.  This  testing  is  relatively 
informal.  Plans  and  procedures  for 
this  testing  and  test  results  will  be 
documented  in  the  sofnvare  develop¬ 
ment  files  (SDFs).  The  contractor  is 
now  working  at  the  lowest  level  of 
abstraction.  As  each  unit  passes  its 
unit  testing,  it  is  made  available  for 
CSC  integration  and  test. 

VVe  now  have  finished  moving  down 
the  abstraction  ladder  and  we  are  ready 
to  move  up  that  ladder,  assembling 
our  pieces  back  into  an  entire  system. 
Computer  software  component  inte¬ 
gration  and  test  is  the  first  step  in  this 
process.  The  SDFs,  introduced  in  the 
preceding  paragraph,  will  be  used  to 
document  and  control  testing  during 
this  step.  Computer  software  units 
are  assembled  into  CSCs  and  tested 
at  that  level.  Interface  problems  be¬ 
tween  the  individual  CSUs,  or  be¬ 
tween  various  CSCs,  are  discovered 
now.  When  the  test  team  is  con¬ 
vinced  that  a  CSC  is  functioning  cor¬ 
rectly,  the  CSC  is  made  available  for 
the  next  level  of  testing.  The  newly 
qualified  CSC  will  be  integrated  with 
other  CSCs  at  its  level,  so  that  a  higher- 
level  CSC  can  be  tested.  When  each 
CSC  at  the  top  level  has  been  tested, 
these  CSCs  will  be  integrated  for  CSCI 
testing. 

Computer  software  configuration 
item  integration  and  test  is  similar  to 
CSC  integration  and  test.  We  as¬ 
semble  the  CSCs  which  comprise  the 
CSCI  and  test  the  entire  computer 
program.  One  or  more  Test  Readi¬ 
ness  Reviews  (TRRs)  will  be  conducted 
prior  to  and  during  this  step.  This 
test  phase  culminates  in  formal  quali¬ 
fication  testing.  This  testing  is  con¬ 
ducted  in  accordance  with  the  soft¬ 
ware  test  plan  and  the  software  test 
description.  Results  of  this  testing 
are  documented  in  the  software  test 
report  (STR).  A  software  functional 
configuration  audit  (FCA)  can  be  con¬ 
ducted  at  any  time  after  CSCI  testing 
is  successfully  completed.  This  audit 


verifies  that  all  requirements  have  been 
incorporated  into  the  design,  and  that 
these  requirements  have  been  ad¬ 
equately  tested.  The  software  prod¬ 
uct  specification,  which  describes  how 
each  computer  software  unit  functions, 
is  finalized  at  the  conclusion  of  this 
step.  A  software  physical  configura¬ 
tion  audit  (PCA)  is  conducted  to  verify 
that  the  CSUs  match  their  descrip¬ 
tions  in  the  SPS.  This  audit  might  be 
delayed  until  successful  completion 
of  system  test. 

The  final  step  is  system  integration 
and  test.  At  this  point,  the  hardware 
and  software  for  the  system  are  inte¬ 
grated  and  final  testing  is  performed. 

The 

40-20-40  Rule 

Now  that  you’re  familiar  with  each 
step  in  the  software  development  pro¬ 
cess,  let’s  examine  one  more  aspect 
of  the  software  development  “V.”  Have 
you  ever  heard  of  the  40-20-40  Rule 
for  software  development?  This  rule 
appears  in  Software  Engineering:  A 
Practitioner’s  Approach  by  Roger  Press¬ 
man.  It  is  a  general  scheduling  rule 
stating  that  approximately  40  percent 
of  the  software  development  effort  will 
be  spent  on  front-end  requirements 
analysis  and  design  tasks,  20  percent 
on  coding,  and  a  full  40  percent  on 
testing  that  code. 

Note  how  this  relates  to  the  soft¬ 
ware  “V”  (See  Figure  4).  The  left  side 
of  the  “V”  represents  the  first  40  per¬ 
cent  of  the  effort.  The  bottom  of  the 
“V”  represents  the  20  percent  of  the 
effort  spent  on  coding.  The  right  side 
of  the  “V”  shows  the  40  percent  of  the 
total  effort  which  is  invested  in  test¬ 
ing. 

Software  Planning 
Documents 

We  have  covered  what  must  be 
done  during  a  software  development 
effort.  Let’s  take  a  look  at  the  two 
master-planning  documents  used  to 
control  this  process: 
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—  Software  Development  Plan 
(SDP) 

—  Computer  Resources  Life-cycle 
Management  Plan  (CRLCMP) 

The  SDP  is  written  by  the  contrac¬ 
tor.  It  tells  how  that  contractor  plans 
to  manage  the  entire  software  devel¬ 
opment  effort.  It  contains  quite  a  bit 
of  information  that  is  not  program- 
specific;  a  particular  contractor’s  ap¬ 
proach  to  software  management  usu¬ 
ally  does  not  change  significantly  from 
project  to  project.  The  SDP  contains 
information  that  is  specific  to  your 
program.  The  SDP  addresses  how 
the  contractor  will  assess  and  man¬ 
age  risk  on  your  program,  and  lists 
highest  priority  risks.  The  SDP  iden¬ 
tifies  the  resources  (people  and  equip¬ 
ment)  the  contractor  plans  to  use  for 
your  program. 

The  CRLCMP  is  written  by  the  gov¬ 
ernment.  The  Computer  Resources 
Working  Group  (CRWG)  is  respon¬ 
sible  for  this  document.  It  contains 
the  government’s  plan  for  managing 
the  computer  system  throughout  its 
entire  life  cycle.  One  of  the  most 
important  sections  addresses  how  soft¬ 
ware  will  be  maintained  once  the  sys¬ 
tem  has  been  fielded.  This  often  re¬ 
quires  many  long  lead  items  (items 
that  cannot  be  obtained  quickly  after 
an  order  is  placed),  like  new  facilities 
or  computer  equipment  at  the  intended 
maintenance  site.  More  information 
on  the  CRLCMP  can  be  found  in  APR 
800-14. 

Conclusion 

We’ve  looked  at  a  definition  of  mis¬ 
sion  critical  computer  resources,  and 
at  the  process  used  for  developing 
this  type  of  software.  We  examined 
the  steps  in  the  software  development 
process,  and  the  documentation,  re¬ 
views  and  audits  associated  with  each 
step.  We  discussed  the  40-20-40  Rule, 
which  provides  guidance  on  schedul¬ 
ing  a  software  development  effort.  We 
discussed  the  two  key  software  plan¬ 
ning  documents. 


This  information  should  help  you 
understand  the  software  development 
process  and  its  impact  on  your  project. 
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KEY  FINDINGS 


LESSONS  LEARNED  IN 
MANUFACTURING 
MODERNIZATION 


Best  Practices  and  Procedures 


ir  Force  acquisition  and 

- 1  manufacturing  managers 

have  had  extensive  experience  in  en¬ 
couraging  the  industrial  base  to  mod¬ 
ernize  its  facilities.  The  goal  of  these 
modernization  efforts  has  typically  in¬ 
cluded  increased  production  efficiency, 
improved  product  quality  and  dura¬ 
bility.  lower  product  life-cycle  costs, 
and  reduced  lead  times.  In  retro¬ 
spect,  some  modernization  efforts  were 
more  effective  than  others. 

This  paper  summarizes  the  key  find¬ 
ings  of  a  study  that  reviewed,  ana¬ 
lyzed  and  identified  the  best  prac¬ 
tices  and  procedures  of  completed 
facility  modernization  efforts  conducted 
under  the  Air  Force  IMIP  program  by 
subcontractors  and  suppliers.'  The 
Department  of  Defense  (DoD)  Indus¬ 
trial  Modernization  Incentives  Pro¬ 
gram  (IMIP)  was  designed  to  moti¬ 
vate  defense  contractors  to  make 
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investments  in  production  modern¬ 
ization  projects  that  are  beneficial  to 
the  government,  and  to  their  compa¬ 
nies.  The  IMIP  projects  were  selected 
for  study  since  the  Air  Force  had  a 
large  experience  base  involving  over 
150  prime  and  subcontractor  compa¬ 
nies  attempting  more  than  500  projects 
in  which  the  industry  had  invested 
over  $  1 .3  billion  dollars  supplemented 
by  $560  million  in  Air  Force  funds. 
The  study’s  primary  goal  was  to  iden¬ 
tify  key  parameters  of  effectiveness 
and  provide  “success  paradigms.”  A 
key  ground  rule  for  the  study  was  that 
there  would  be  no  attribution  to  any 
of  the  parties  involved  in  the  selected 
projects. 

Modernization  efforts  at  subcon¬ 
tractor  facilities  were  accomplished 
either  under  the  cognizance  of  a  prime 
weapon  system  contractor  or  directly 
with  an  Air  Force  program  office.  This 
segment  of  the  industry  was  chosen 
for  the  study  because  subcontrac¬ 
tors  comprise  a  large  portion  of 
the  industrial  base  and  pier- 
form  the  lion’s  share 
of  hands-on 
manufacturing 
for  most  major 
weapon  sys¬ 
tems.^  Many  support 

several  weapon  systems  so  that  sub¬ 
stantial  leverage  is  achieved  when  their 
production  capabilities  are  upgraded. 


The  facility  modernization  process 
traditionally  has  comprised  four 
phases.^ ''  During  a  company-initiated 
Phase  0,  the  contractor  and  prime/ 
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government  establish  the  overall  scope 
of  the  effort  and  define  specific  goals. 

The  next  phase  (Phase  I),  “Facility 
Analysis  and  Project  Identification," 
develops  the  discipline  and  blueprint 
for  future  factory  modernization.  The 
baseline  (or  “as  is")  facility  is  described 
using  a  systems  engineering  approach 
such  as  the  Integrated  Computer  Aided 
Manufacturing  Definition  Language 
0  (IDFF,).’'’  Potential  improvement 
projects  are  then  analyzed  to  deter¬ 
mine  the  effect  on  the  total  facility, 
and  to  estimate  their  development  and 
implementation  cost.  These  projects 
form  the  basis  for  the  improved  ("to 


The  goal  of  these 
modemizotion 
efforts  hos  typically 
included  Increased 
production 
efficiency, 
improved  product 
quality  ond 
durobility,  lower 
product  life-cycle 
costs,  ond 
reduced  lead 
times. 


potential,  improvement  concepts,  cost/ 
benefit  analysis,  business  strategy  re¬ 
lated  to  modernization,  capital  invest¬ 
ment  plans,  and  an  implementation 
time  table. 

The  conceptual  facility  layouts, 
developed  during  Phase  1,  scope  and 
focus  the  activity  for  Phase  11,  “Project 
Design  and  Development."  The  ma- 


ing  detailed  cost/benefits  analyses,  re¬ 
fining  business  strategy,  and  planning 
for  implementation. 

Implementation  usually  occurs  dur¬ 
ing  Phase  III,  which  can  be  concur¬ 
rent  with  part  of  Phase  II.  Capital 
equipment  must  be  purchased  and 
integrated  into  the  company’s  manu¬ 
facturing  operations,  and  benefits  vali¬ 
dated. 

The  following  sections  of  this  pa¬ 
per  describe  the  method  used  to  se¬ 
lect  the  projects  for  study,  the  deter¬ 
mination  of  the  key  characteristics  of 
the  successful  projects,  and  key  les¬ 
sons  learned  for  future  facility  mod¬ 
ernization  projects. 

Selection  of  Subcontractor/ 
Supplier  Projects 

A  semiquantitative  selection  meth¬ 
odology  was  used  to  rank  completed 
facility  modernization  projects  in  or¬ 
der  of  effectiveness  to  ensure  that  pro¬ 
grams  across  the  Air  Force  Material 
Command  were  considered  on  an  equal 
basis.  The  five  criteria  used  are  shown 
in  Table  1 .  Weight  factors  and  rating 
guidelines  for  each  criterion  were  de¬ 
veloped  based  on  input  from  the  Air 
Force  program  managers  and  manu¬ 
facturing  experts.  This  allowed  for 


TABLE  I .  Project  Selection  Criteria 


Criterion 

Weight  (w.) 

■ .  Project  Impact  on  Production  Facility 

5 

2.  Number  of  Weapon  Systems  Affected 

1 

3.  Extent  of  Production  Facility  Affected 

3 

4.  Time  Required  to  Complete  Phases  II  &  III 

1 

5.  Continuation  of  Modernization 

2 

be")  facility.  Phase  I  is  an  essential 
element  of  a  company’s  Strategic 
Modernization  Plan  (SMP),  which  in¬ 
cludes  a  projection  of  future  business 


jority  of  the  Phase  II  effort  involves 
accomplishing  detailed  designs  for  each 
selected  modernization  project,  dem¬ 
onstrating  proof  of  concept,  perform- 


projects  to  be  rated  on  a  common 
basis.  The  criteria  were  applied  using 
a  Multiattribute  Utility  (MAU)  analy¬ 
sis  approach.  Each  criterion  could  be 
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rated  from  0  points  (worst  case)  to 
100  points  (best  case). 

When  the  projects  were  rank-or¬ 
dered  by  total  points  (which  repre¬ 
sented  the  degree  of  effectiveness), 
the  highly  rated,  most  effective  projects 
were  grouped  at  the  top.  The  least 
effective  ones  were  at  the  bottom.  Ad¬ 
ditional  criteria  were  then  used  to  en¬ 
sure  that  the  selected  projects  were 
balanced  between  degrees  of  effec¬ 
tiveness,  Air  Force  weapon  sy:tcms 
and  industry  segments.  Twelve  sub¬ 
contractor  manufacturing  moderniza¬ 
tion  programs  involving  78  modern¬ 


ization  projects  were  selected  for  de¬ 
tailed  evaluation. 

Key  Characteristics 

Key  aspects  and  subprocesses  of 
the  selected  projects  served  as  a  frame¬ 
work  for  organizing  and  evaluating 
the  collection  of  data.  Key  features 
were  compared  and  contrasted  for  the 
most-effective  and  the  least-effective 


projects,  allowing  the  determination 
of  which  specific  aspects  and  subpro¬ 
cesses  were  indeed  critical  in  predict¬ 
ing  the  overall  effectiveness  of  the 
projects.  Eleven  key  characteristics 
are  listed  in  Table  2.  After  analysis, 
four  were  found  to  be  critical  indica¬ 
tors  of  success  (Table  4).  The  key 
characteristics  were  all  important  for 
success.  The  critical  factors  were  those 
that  clearly  differentiated  the  most  suc¬ 
cessful  from  the  least  successful 
projects. 

1 .  Maturity  of  the  Weapon  System 
Supported  was  a  significant  factor  only 
to  the  extent  that 
future  production 
orders  could  be 
anticipated. 

2.  Stability  of 
the  Weapon  Sys¬ 
tem  Supported 
was  an  important 
factor.  It  was  es¬ 
pecially  important 
for  those  whose 
business  base 
was  mostly  de¬ 
fense  related. 
Size  of  the  Pro¬ 
gram  Supported 
did  not  appear 
significant:  nearly 
every  weapon 
system  included 
in  the  study  was 
in  the  SlOOs  mil¬ 
lion  category. 


3.  Business 
Strategies  of  the 
Suppliers  were 
very  important  in 
understanding  the  business  climate 
in  which  the  companies  operated.  Ev¬ 
ery  supplier  had  mostly  firm-fixed- 
price  contracts.  Some  had  multiyear 
contracts,  but  did  not  view  them  as 
important  as  becoming  a  “preferred” 
supplier  to  a  prime.  Most  of  the  com¬ 
panies  had  more  than  10  percent  of 
their  business  in  the  nongovernment, 
commercial  sector,  and  were  forecast¬ 
ing  this  percentage  to  increase.  Those 


TABLE  2.  IMIP  Key  Characteristics 


1. 

Maturity  of  the  Weapon  Systems 

Supported 

2. 

Stability  and  Size  of  the  Weapon 

Systems  Supported 

3. 

Business  Strategy  (Company) 

4. 

Technical  Approaches  to  Top-Down 

Facility  Architecture 

5. 

Requests  for  Proposals/Phase  1  Contract 
and  SOW  Adequacy 

6. 

Use  of  Supporting  Consultants 

7. 

Adequacy  of  Phase  II 

8. 

Adequacy  of  Phase  III 

9. 

Time  to  Accomplish  IMIP  Phases  1  and  II 

10. 

Contractor  Executive  Management 
Commitment  to  Factory  Modernization 

11. 

Business  Characteristics  (Demographics) 
of  the  Subcontractor 

with  the  most  commercial  work  were 
particularly  interested  in  the  applica¬ 
bility  of  the  factory  modernization  and 
new  process  technology  to  their  com¬ 
mercial  products.  All  the  companies 
had  a  wide  production  base  and  were 
not  overly  dependent  on  a  single  cus¬ 
tomer.  Many  had  an  appreciable  busi¬ 
ness  in  providing  replacement  parts 
and  logistic  services. 

4.  Technical  Approach  to  Top-Down 
Factory  Architecture  in  the  Phase  I 
study  efforts  included  use  of  the  IDEF^, 
methodology  in  the  definition  of  the 
baseline  “as  is”  facility  and  the  im¬ 
proved  “to  be”  facility.  The  most  ex¬ 
tensive  use  of  IDEF^,  concerned  the 
development  of  the  node  tree  analy¬ 
sis  for  production  activities.  This  tree 
was  commonly  used  as  a  framework 
to  analyze  cost  and  schedule  drivers. 
A  typical  issue  encountered  was  the 
lack  of  sophistication  and  wide  diver¬ 
sity  of  a  company’s  cost-capturing  sys¬ 
tems  which  often  led  to  the  use  of 
"engineering  estimates”  for  the  assign¬ 
ment  of  costs  to  the  various  nodes. 
Many  companies  were  surprised  by 
some  of  the  results.  In  several  cases, 
this  precipitated  a  much  more  exten¬ 
sive  modernization  effort  than  was 
initially  planned. 

Other  system  engineering  ap¬ 
proaches  were  employed  as  well.  These 
included:  simulations,  facility  layouts, 
value  analysis  techniques,  flowcharts, 
activity-based  costing,  and  product 
cost  decompositions.  Most  of  the  time, 
these  were  accomplished  by  special¬ 
ized  tools  used  by  consultants. 

In  nearly  every  case,  an  attempt 
was  made  at  the  beginning  of  Phase 
II  to  show  traceability  to  the  Phase  I 
analysis.  However,  the  degree  of  trace- 
ability  ranged  from  excellent  to  mar¬ 
ginal.  Surprisingly,  most  companies, 
prior  to  IMIP,  had  done  minimal  mod¬ 
ernization  planning  other  than  replac¬ 
ing  items  of  equipment,  such  as  ma¬ 
chine  tools.  The  Phase  I  study  was 
essentially  their  first  significant  op¬ 
portunity  to  consider  the  future  of 
their  facility,  and  many  thought  that 
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this  effort  alone  was  extremely  worth¬ 
while.  Many  companies  continued 
to  maintain  and  update  the  Strategic 
Modernization  Plan  after  the  IMIP 
Phase  I  was  completed. 

5.  The  effectiveness  criteria  for 
Phase  I  RFP,  Contract,  and  SOW  Ad¬ 
equacy  were  based  on  evaluating  how 
well  the  contracting  process  commu¬ 
nicated  the  government’s  requirements. 
In  all  cases,  these  aspects  were  found 
to  be  satisfactory. 

6.  Nearly  every  project  made  Use 
of  Supporting  Consultants  during  Phase 
I.  Typical  Phase  I  activities  performed 
by  consultants  included  development 
of  the  top-down  facility  analysis,  team 
training,  evaluation  of  baselines,  analy¬ 
sis  of  candidate  projects,  and  techni¬ 
cal  approaches  for  candidate  projects. 
The  type  of  consultants  used  ranged 
from  assistance  provided  by  prime 
contractors,  to  using  a  corporate  team 
of  experts  (for  those  companies  that 
were  part  of  larger  corporate  family), 
to  specialized  consultants  selected 
through  a  competitive  process.  Is¬ 
sues  raised  about  using  consultants 
were:  (a)  Some  were  not  expert  in 
specific  details  of  the  company's  busi¬ 
ness.  so  a  period  of  time  was  required 
to  “bring  them  up  to  speed”;  (b)  a 
tendency  to  force-ht  all  problems  into 
their  methodologies  and  tool  set  even 
when  they  were  not  appropriate:  and 
(c)  too  extensive  an  involvement  in 
evaluating  and  selecting  improvement 
projects  during  Phase  I  was  not  effec¬ 
tive  because  the  knowledge  tended  to 
leave  with  the  consultant — correspond¬ 
ingly,  the  company’s  personnel  did 
not  have  a  high  degree  of  ownership 
of  the  results. 

Phase  I  programs  that  did  not  use 
consultants  were  generally  less  effec¬ 
tive  than  those  that  did.  The  amount 
of  effort  contributed  by  consultants 
varied  significantly.  The  most  impor¬ 
tant  factor  was  the  way  in  which  con¬ 
sultants  were  used.  When  they  sup¬ 
ported  an  in-house  team  and  had  a 
clearly  defined  and  understood  role, 
they  contributed  effectively.  When 


consultants  were  hired  to  “fill  a  square" 
and  were  not  incorporated  as  part  of 
the  company’s  team,  their  contribu¬ 
tion  was  markedly  reduced. 

7.  Adequacy  of  Phase  II  was  based 
on  an  examination  of  the  quality  of 
the  effort.  As  would  be  expected,  the 
adequacy  of  Phase  II  paralleled  the 
effectiveness  ratings.  The  more  effec¬ 
tive  efforts  accomplished  Phase  II 
projects  within  the  resources  that  were 
planned;  although,  in  many  cases 
Phase  II  projects  took  somewhat  longer 
to  complete  than  originally  planned. 
In  almost  every  instance,  time  and 
effort  to  develop  new  software  was 
greatly  underestimated.  This  was  true 
for  software  to 


For  Case  A,  lack  of  a  reasonable 
payoff  did  not  necessarily  mean  there 
was  insufficient  payoff  for  the  De¬ 
partment  of  Defense  as  a  whole,  but 
for  the  sponsoring  Air  Force  program 
office.  The  lack  of  a  commonly  ac¬ 
cepted  standard  approach  to  define 
savings  of  “intangible”  benefits,  like 
improved  quality,  reduced  indirect 
costs,  shorter  lead  times,  and  so  on, 
led  to  unfavorable  return-on-invest- 
ment  (ROD  using  a  discounted  cash 
flow  model  even  though  overall  ben¬ 
efits  were  thought  to  be  significant. 

There  were  examples  in  which  the 
Phase  II  analysis  determined  there 
was  insufficient  payoff  to  proceed. 


control  machine 
tools  and  for  soft¬ 
ware  that  sup¬ 
ported  facility 
information  sys¬ 
tems. 

In  general,  the 
smaller  compa¬ 
nies  tended  to 
overestimate  the 
number  of  simul¬ 
taneous  projects 
that  could  be 
managed  effec¬ 
tively  using  their 
normal  manage¬ 
ment  style.  Those 
projects  that  com¬ 
pleted  Phase  II 
development  on 
the  same  hard¬ 
ware/software 
systems  that 
would  be  used  in 


production  were 

more  effective,  even  though  this  ap-  ’These  instances  were  due  to  ix)orben- 
proach  required  early  capital  invest-  efits  definition,  inadequate  definition 
ments.  during  Phase  1,  or  a  reduction  in  De¬ 

partment  of  Defense  orders. 


Projects  terminated  during  Phase 
II  fell  into  three  categories:  (A)  tech¬ 
nically  successful  but  not  economically 
viable;  (B)  technical  failures;  and  (C) 
technically  successful/doable,  but  su¬ 
perseded  by  a  better,  less-expensive 
alternative. 


For  Case  B,  the  less  effective  pro¬ 
grams  tended  to  “throw  in  the  towel” 
when  unexpected  and  complex  tech¬ 
nical  challenges  arose,  while  the  more 
effective  programs  solved  the  chal¬ 
lenges.  This  is  indicative  of  the  ground- 
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TABLE  4.  Critical  Characteristic  Analysis 


Effectiveness 

Rating 

Business  Strategy 
Percent  Commercial 
Business 

Technical 

Approaches  to 

Phase  1 

Phase  1  Adequacy 

Main  Thrust  of  Modernization 
Effort 

Contractor  Management 
Commitment 

Multidiscipline,  Full-Time 
Team 

A 

50  to  70 

Facility-wide 

Factory-wide  modernization 

Yes 

A 

50  to  70 

Facility-wide 

Enterprise  Information 

System 

Yes 

A 

10  to  25 

Facility-wide 

Quality  and  Mfg  Info  System 

Yes 

A 

1 0  or  less 

Facility-wide 

Specific  process 

Improvements 

Yes,  except 

Engineering 

B 

10  to  25 

Facility-wide 

Manufacturing  Information 
Systems,  Quality,  Auto 
Assembly 

Yes 

B 

10  to  25 

Product  Specific 

Mfg  Info  Systems  and 

Indirect,  Process  Upgrades 

Yes,  except 
Manufacturing 

B 

10  to  25 

Facility-wide 

Quality 

Yes 

C 

50  to  70 

Product  Specific 

Specific  Process 
Improvements,  not 

Automation 

Yes  (PM  only  Full  Time) 

C 

greater  than  70 

Equipment  Specific 

Specific  Automation  Projects 

At  start,  not  continued 

C 

greater  than  70 

Operation  Specific 

Manufacturing  Information 
Systems 

At  start,  not  continued 

C 

1 0  or  less 

Operation  Specific 

Quality  and  Auto  Assembly 

At  start,  not  continued 

D 

1 0  or  less 

Operation  Specific 

Specific  Automation 

At  start,  not  continued 

work  laid  during  Phase  I.  Less-effec¬ 
tive  programs  tended  to  orient  the 
Phase  I  analysis  toward  a  high  degree 
of  automation,  and  took  an  overly 
simplistic  view  of  what  it  really  takes 
to  automate  a  process.  The  more 
effective  programs  used  a  more  prag¬ 
matic  approach  for  automation.  Gov¬ 
ernment  policies  that  emphasize  capital 
investment  tend  to  “push"  subcon¬ 
tractors  toward  a  higher  degree  of  au¬ 
tomation  than  may  be  worthwhile. 

Case  C  was  usually  caused  by  in¬ 
complete  technical  analyses  performed 
during  Phase  I.  For  example,  while  a 
project  was  taking  one  approach  to 
greatly  improve  the  repair  procedure 
for  an  expensive  metalworking  die, 
another  group  in  the  same  company 
was  changing  the  die  design  to  elimi¬ 
nate  the  cause  of  the  failure  mode. 
This  was  symptomatic  of  many  projects 
that  fell  in  this  category:  namely,  there 
was  insufficient  consideration  in  Phase 
I  to  address  the  root  cause  of  the 


identified  problems  and  to  trade-off 
solutions. 

8.  Adequacy  of  Phase  III  was  as¬ 
sessed  by  evaluating  how  closely  imple¬ 
mentations  followed  the  plan  and  pro¬ 
duced  expected  benefits.  In  many 
cases,  the  Phase  III  implementations 
took  longer  than  estimated.  This  was 
usually  due  to  the  pressures  of  in¬ 
stant  business.  It  was  almost  always 
more  important  for  the  company  to 
satisfy  current  orders  than  to  stop  the 
production  process  or  to  take  key  per¬ 
sonnel  away  from  a  key  job  to  imple¬ 
ment  improvements. 

9.  Time  to  Accomplish  Phases  re¬ 
vealed  that  most  programs  experienced 
large  time  gaps  between  phases. 
Equally  distressing  was  the  stretch¬ 
out  of  Phase  II  programs  due  to  inad¬ 
equate  funding  rates.  The  length  of 
Phases  I  and  II,  and  the  gap  between 
the  two  phases,  for  the  12  IMIPs  ranged 
from  a  few  months  to  more  than  24 


months.  Sequential  funding  of  mul¬ 
tiple  Phase  II  projects  at  a  sub¬ 
contractor’s  facility  led  in  some  in¬ 
stances  to  the  modernization  program 
stretching  over  many  years.  Gaps 
between  phases  had  an  especially  se¬ 
vere  impact  at  small  companies  which 
found  it  difficult  to  return  to  a  high 
level  of  enthusiasm  and  commitment 
after  a  protracted  wait. 

10.  Assessing  the  Contractor  Ex¬ 
ecutive  Management  Commitment  was 
measured  by  the  formation  of  a 
multidisciplinary  team.  The  most  ef¬ 
fective  programs  had  a  full-time  team 
led  by  a  senior  manager  wh  reported 
directly  to  the  president  or  chief  ex¬ 
ecutive  officer.  Team  members  were 
from  different  organizations  within  the 
company  and  represented  a  spectrum 
of  appropriate  disciplines. 

Another  measure  of  the  man¬ 
agement’s  commitment  was  the 
amount  of  capital  investment  made 
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by  the  company.  In  this  respect,  com¬ 
paring  the  average  age  of  equipments 
before  IMIP  with  that  after  modern¬ 
ization  implementation  can  be  enlight¬ 
ening.  Table  3  summarizes  the  data 
collected  during  this  study.  Companies 
are  listed  in  order  of  effectiveness. 

Dramatic  reductions  in  average  age 
of  equipment  are  associated  with  the 
modernization  projects  that  were  rated 
high  on  effectiveness.  Not  all  capital 
investments  included  within  this  study 
were  directly  due  to  the  moderniza¬ 
tion  projects,  but  many  investment 
decisions  were  significantly  influenced 
by  the  facility  analysis. 

In  some  cases  the  average  age  of 
equipment  was  not  meaningful  due 
to  several  factors.  Phase  I  analysis, 
in  some  instances,  pointed  out  the 
high  cost  of  maintaining  multiple  plant 
sites:  these  were  consolidated  and  older 
equipment  surplused.  Thus,  the  av¬ 
erage  age  decreased  but  not  due  to 
capital  expenditures. 

The  age  of  an  item  of  equipment, 
such  as  a  machine  tool,  is  determined 
by  its  acquisition  date.  Thus,  the  age 
of  record  is  not  changed  even  when 
the  equipment  is  upgraded. 

Several  factories  had  a  wide  range 
of  equipment  types  such  as  vacuum 
furnaces  and  microelectronic  assem¬ 
bly  stations.  The  companies  had  mod¬ 
ernized  the  equipment  that  was  cru¬ 
cial  to  the  manufacture  of  its  high 
technology  products;  only  moderate 
upgrades  were  made  to  the  remaining 
equipment.  This  led  to  a  bimodal  dis¬ 
tribution  of  equipment  age. 

1 1 .  Business  Characteristics  of  the 
Suhcontractor/Vendor  is  the  demo¬ 
graphic  information  about  the  com¬ 
panies.  Sizes  of  companies  varied  by 
an  order  of  magnitude  from  a  low  of 
$45  million  to  a  high  of  $490  million 
annual  sales.  The  industry  sectors  rep¬ 
resented  by  the  1 2  companies  included 
electrical  and  electronic  equipment, 
metalworking,  casting,  metal  products 
and  aerospace  manufacturing. 
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Critical  Characteristics 

Of  the  key  characteristics  exam¬ 
ined,  four  were  found  to  be  critical. 
In  this  context,  “critical”  is  defined  as 
a  characteristic  that  could  predict  and 
influence  effectiveness  of  the  mod¬ 
ernization  effort  to  a  significant  de¬ 
gree.  A  synopsis  of  the  critical  char¬ 
acteristic  data  is  presented  in  Table 
4.  Effectiveness  ratings  are  given  in 
letter  grades  ranging  from  A  (very  ef¬ 
fective)  to  D  (not  very  effective).  This 
was  done  to  group  those  programs 
with  similar  numerical  scores.  The 
four  critical  characteristics  follow. 

— Business  Strategies  (Company)  as 
indicated  by  percent  commercial  busi¬ 
ness.  (Other  metrics  of  this  charac¬ 
teristic  generally  followed  the  same 
trend.)  Typically,  a  company  needed 
commercial  business  to  realize  an  at¬ 
tractive  retum-on-investment  for  capital 
expenses.  Government  incentives 
alone  were  perceived  to  be  unreliable 
or  inadequate.  The  two  least-effec¬ 
tive  programs  had  less  than  5  percent 
commercial  business  and  thus  did  not 
have  sufficient  commercial  business 
to  generate  the  additional  required 
payoff. 

— Technical  Approaches  to  top-down 
facility  analysis,  as  indicated  by  the 
technical  approach  to  modernization. 
The  first  was  the  traditional  approach 
of  quickly  zeroing  in  on  obvious,  spe¬ 
cific  improvements  relating  to  particular 


operations,  pieces  of  equipment,  or 
subassemblies/products.  This  ap¬ 
proach  resulted  in  projects  that  ranged 
in  effectiveness  from  above  average 
to  much  below  average.  The  other 
approach  started  with  a  comprehen¬ 
sive  facility-wide  analysis  to  establish 
a  framework  for  judging  the  relative 
payoff  of  improvements  from  a  "sys¬ 
tems  perspective”  of  the  entire  enter¬ 
prise.  The  facility-wide  analysis  ap¬ 
proach  produced  the  most-effective 
efforts.  For  example,  a  company  with 
a  highly-effective  program  had  a  prior 
modernization  strategy  that  planned 
to  replace  old  equipment.  However, 
as  a  result  of  the  Phase  I  analysis,  a 
decision  was  made  to  proceed  with 
the  complete  revamping  of  the  facil¬ 
ity,  which  included  substantial  rear¬ 
rangement  of  the  process  flow.  Nearly 
the  same  equipment  was  acquired, 
but  it  was  employed  more  effectively 
than  originally  envisioned. 

— Phase  I  Adequacy,  as  indicated 
by  the  focus  of  the  analysis:  i.e., 
enterprise-wide,  quality,  MIS,  process 
specific  improvements,  etc.  (Adequacy 
of  the  Phase  1  plan  is  related  to  the 
technical  approaches  critical  charac¬ 
teristic.)  Those  which  only  empha¬ 
sized  specific  process  improvements 
were  not  necessarily  failures  but  were 
not  as  effective,  in  general,  as  those 
which  made  system-wide  improve¬ 
ments  in  conjunction  with  process 
improvements.  Using  the  systems 
approach,  important  considerations 
for  “above-the-shop  floor”  processes 
(e.g.,  application  of  group  technol¬ 
ogy,  material  handling  improvements, 
and  maintenance  of  the  software  for 
automated  operations)  were  ad¬ 
equately  addressed.  In  essence,  this 
critical  characteristic  is  the  assess¬ 
ment  of  how  well  the  technical  ap¬ 
proach  was  performed. 

Contractor  Executive  Management 
Commitment  to  facility  modernization, 
as  indicated  by  the  formation  of  a  full¬ 
time,  multidisciplinary  team.  The  com¬ 
mitment  of  company  senior  manage¬ 
ment  is  imperative.  Programs  with 
strong  management  backing  were  able 
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to  overcome  obstacles  including  tech¬ 
nical  surprises,  gaps  in  government 
funding,  and  incentives  which  were 
less  than  anticipated. 

Lessons  Learned 

Future  manufacturing  moderniza¬ 
tion  programs  can  incorporate  the  best 
practices  of  past  programs  to  reduce 
their  risk  and  cost.  This  section  sum¬ 
marizes  what  worked  particularly  well 
and  what  should  be  avoided. 

Lesson  Learned  1:  Successful 
Manufacturing  Modernization 
Programs  Require  High-Level 
Corporate  Commitment 

— The  most  important  factor  in  the 
success  of  a  program  is  a  consistent 
and  continuing  top-level  company 
management  commitment.  All  sources 
of  information  confirmed  the  neces¬ 
sity  for  senior  management  to  place 
necessary  emphasis  on  the  program, 
and  to  ensure  availability  of  resources 
to  plan,  analyze,  develop  and  execute 
the  program.  As  problems  arose  dur¬ 
ing  the  conduct  of  the  program,  those 
with  the  corporate  management  com¬ 
mitment  managed  to  overcome  them 
to  a  far  greater  extent  than  those  that 
did  not  have  such  a  commitment. 

— Smaller,  privately-held  compa¬ 
nies  gained  top-management  support 
for  development  of  a  strategic  mod¬ 
ernization  plan  (SMP)  in  a  relatively 
straightforward  manner.  Publicly-held 
companies,  particularly  members  of 
a  corporate  family,  required  additional 
time  to  obtain  upper-level  company 
management  commitment. 

— The  first  concrete  sign  of  a  seri¬ 
ous  commitment  was  the  formation 
of  a  multidisciplinary  team  at  the  start 
of  Phase  0.  An  important  outcome  of 
this  activity  was  development  of  spe¬ 
cific  goals  regarding  modernization 
opportunities  and  expected  benefits 
to  company  and  customer.  In  gen¬ 
eral,  potential  contract  funding  sup¬ 
port,  and  incentives  for  future  sav¬ 
ings  were  significant  enticements  for 


management,  even  when  capital 
spending  approval  had  not  previously 
been  forthcoming. 

The  most  effective  programs  resulted 
in  wide-ranging  changes  within  the 
company.  However,  corporate  cul¬ 
ture  takes  time  to  change  and  requires 
involvement  by  all  levels  of  the  work 
force.  The  commitment  by  senior 
management  helps  promote  this  flow- 
down  throughout  the  company.  Ben¬ 
efits  of  involving  the  entire  company 
included  continued  improvement 
through  education  and  training,  de¬ 
velopment  of  a  wealth  of  improve¬ 
ment  ideas,  a  wide  base  of  support 
for  implementation  and  pride  of  own¬ 
ership  in  results. 

— Some  less-su^^essful  moderniza¬ 
tion  projects  had  top-level  commit¬ 
ment,  but  had  an  appreciable  amount 
of  the  Phase  1  effort  accomplished  by 
consultants  who  were  not  under  the 
direction  and  support  of  an  in-house 
team.  Unfortunately,  little  internal 
interest  at  the  “working  level”  was 
developed  to  pursue  projects  once  the 
consultants  left.  Technical  and/or 
implementation  issues  tended  to  be¬ 
come  obstacles  and  often  were  used 
as  reasons  to  cancel  projects.  On  the 
other  hand,  companies  which  estab¬ 
lished  a  strong  in-house  team  supple¬ 
mented  by  outside  expertise  were  gen¬ 
erally  successful. 

— Usually  the  subcontractor’s  first 
in-depth  exposure  to  factory  modern¬ 
ization  was  through  a  prime  contrac¬ 
tor.  The  subcontractor’s  executives 
typically  viewed  modernization  first 
as  an  opportunity  to  enhance  their 
business  relationship  with  the  prime, 
possibly  by  becoming  a  preferred  sup¬ 
plier.  The  opportunity  to  improve 
their  competitive  advantage  by  mod¬ 
ernizing  facility  operations  was  a  strong 
additional  incentive. 

Lesson  Learned  2:  Strategic  Mod¬ 
ernization  Plan  Critically  Important 

— Highly  effective  modernization 
was  accomplished  by  companies  that 


developed  long-range  strategic  plans 
for  improvements  addressing  concrete 
needs.  Plans  affected  direct  and  indi¬ 
rect  facility  areas  in  an  integrated  fash¬ 
ion  so  that  individual  areas  were  not 
suboptimized.  A  sound  technical  ap¬ 
proach  using  a  variety  of  engineering 
analysis  tools  guided  by  a  system  en¬ 
gineering  approach  was  necessary 
to  attack  root  causes  of  problems,  not 
symptoms.  For  example,  a  subcon¬ 
tractor  with  an  effective  moderniza¬ 
tion  program  had  a  key  supplier  with 
a  persistent  quality  problem.  Rather 
than  automating  receiving  insp>ection, 
the  subcontractor  worked  with  the 
supplier’s  manufacturing  process  to 
attack  the  root  cause  of  the  quality 
deficiency. 

— Less-effective  programs  rapidly 
converged  on  improvement  projects 
which  had  benefits  that  could  be  quan¬ 
tified  for  a  particular  production  pro¬ 
cess,  but  which  were  not  the  most 
important  from  a  strategic  viewpoint. 
For  example,  one  program  focused 
on  automatii  .g  manual  operations  that 
accounted  for  only  a  small  percent¬ 
age  of  manufacturing  costs  and  qual¬ 
ity  problems,  while  costly  operations 
were  ignored  because  they  could  not 
be  easily  automated. 

— Prioritization  of  efforts  ensures 
that  the  most  important  projects  are 
accomplished  first.  This  is  facilitated 
by  a  comprehensive  facility-wide  analy¬ 
sis  as  part  of  a  company’s  strategic 
plan.  TTie  most  effective  strategic  plans 
ensured  that  the  modernization  projects 
fit  together  realistically.  For  example, 
a  successful  company  that  had  a  stra¬ 
tegic  goal  of  reducing  work-in-process 
(WIP),  established  a  comprehensive 
plan  for  just-in-time  (IIT)  inventory 
control  that  included  rearrangement 
of  machine  tools,  upgrades  to  equip¬ 
ment,  improvements  to  the  factory 
information  systems,  training  for  shop- 
floor  personnel  and  production  plan¬ 
ners,  and  incentive  arrangements  with 
their  suppliers. 

— Improper  use  of  discounted  cash 
flow  models  during  Phase  I  led  to 
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erroneous  management  decisions  re¬ 
garding  the  true  viability  of  improve¬ 
ment  projects.  Typical  sources  of  er¬ 
ror  included  cost  data  of  dubious 
accuracy,  overly  optimistic  business 
projections,  and  underestimation  of 
implementation  costs.  Inevitably,  these 
mistakes  became  obvious  during  Phase 
II  after  significant  time  and  effort  had 
been  expended  on  ill-fated  projects 
with  little,  if  any,  chance  of  imple¬ 
mentation. 

—Over-reliance  on  discounted  cash¬ 
flow  models  to  prioritize  projects  cre¬ 
ated  the  following  types  of  issues;  (a) 
overemphasis  on  the  automation  of 
manual  operations  due  to  an  appar¬ 
ently  easy  determination  of  savings 
from  reduced  direct  labor  and  rea¬ 
sonably  good  estimate  of  capital  in¬ 
vestment  needs;  and  (b)  neglect  of 
the  major  savings  potential  in  the  in¬ 
direct  areas  that  often  required  little 
capital  investment. 

— Effective  modernization  programs 
maintained  an  implementation  focus. 
Projects  were  pursued  that  could  be 
readily  implemented.  If  some  diffi¬ 
culty  was  anticipated,  a  mitigation  strat¬ 
egy  was  developed.  Resistance  to 
change  was  an  implementation  bar¬ 
rier  highlighted  by  nearly  every  com¬ 
pany.  Successful  companies  estab¬ 
lished  a  continuing  dialogue  with  the 
work  force  explaining  the  changes  and 
the  expected  results.  They  followed 
through  with  necessary  training. 

— Effective  modernization  programs 
became  part  of  the  company’s  overall 
strategy  to  become  a  "world  class 
manufacturer."  One  company  estab¬ 
lished  a  special  position  of  "world 
class  manufacturing  manager."  This 
infused  the  entire  company  with  a 
dedication  toward  manufacturing  ex¬ 
cellence  that  transcended  the  original 
goals  of  the  modernization  effort. 

Lesson  Learned  3:  Significant 
Obstacles  to  Implementation  Exist 

— Time  delays  for  approvals  and 
contractual  actions  were  responsible 
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for  loss  of  effectiveness  in  the  IMIP 
programs  at  the  subcontractor  level. 
Unilateral  revision  of  the  rewards,  for 
whatever  reason,  was  a  negative  fac¬ 
tor  in  the  implementation  decision. 

— In  instances  where  moderniza¬ 
tion  projects  impacted  product  lines 
across  multiple  weapon  system  pro¬ 
grams,  implementation  planning  did 
not  always  allocate  the  time  or  effort 
for  changes  in  engineering  technical 
data  to  be  made  since  the  scope  was 
too  narrowly  viewed  as  being  manu¬ 
facturing-based.  Sizeable  productiv¬ 
ity  payoffs  were  missed  particularly 
when  significant  changes  to  the  qual¬ 
ity  verification  methods  were  accom¬ 
plished  by  a  facility  modernization 
project,  but  could  not  be  implemented 
on  the  production  floor  because  not 
all  affected  primes  had  an  opportu¬ 
nity  to  evaluate  adequacy  of  the  change 
for  their  components. 

Summary 

The  health  of  the  defense  indus¬ 
trial  base  is  a  vital  ingredient  in  our 
country’s  total  military  capability.  This 
industrial  base  includes  many  sub¬ 
contractors  and  suppliers  who  pro¬ 
vide  critical  support  to  prime  weapon 
system  contractors  and  follow-on  sup¬ 
port  to  logistic  centers.  Their  overall 
health  encompasses  financial  and  up- 
to-date  manufacturing  capability.  It 
is  very  important  that  the  time  and 
resources  devoted  to  modernizing  their 
facilities  are  spent  effectively. 


The  lessons  learned  identified  dur¬ 
ing  this  study  provide  a  clear  blue¬ 
print  for  improving  future  facility  mod¬ 
ernization  projects.  They  include; 
required  corporate  commitment  by 
senior  management;  a  company’s  stra¬ 
tegic  modernization  plan  to  be  criti¬ 
cally  important  as  the  framework  for 
improvements;  and  (3)  mitigating  ob¬ 
stacles  to  implementing  projects 
through  early  involvement  of  key 
people. 
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RECYCLING 


THE  ARMY  REUSE  CENTER- 
COST  AVOIDANCE  THROUGH 
SOFTWARE  REUSE 

Software  Development  Support  for 
Program  Managers 

Marrea  Riggs 

Director,  Army  Reuse  Center 


IP  i  rogram  managers  are  under 
•  constant  pressure  to  provide 
their  users  with  top-notch  products 
on  time  and  within  budget.  The  Army 
Reuse  Center  (ARC)  staff  understands 
those  requirements.  The  ARC  was 
established  to  support  the  develop¬ 
ment  and  fielding  of  reliable,  high- 
quality  systems,  reduce  the  time  and 
resources  required  to  develop  those 
systems,  and  reduce  software  life-cycle 
costs.  These  objectives  can  be  achieved 
through  the  effective  application  of 
software  reuse. 

The  ARC  is  in  the  business  of 
working  with  program  managers  to 
incorporate  software  reuse  into  each 
phase  of  the  development  life  cycle. 
The  ARC  provides,  through  its  effec¬ 
tive,  automated  library  system,  an  ar¬ 
ray  of  high-quality,  reusable  software 
components  and  a  range  of  reuse 
engineering  support.  Its  mission  is  to 
make  planned,  systematic  reuse  an 
integral  part  of  the  Army’s  day-to-day 
development  efforts.  The  ARC’S 
approach  addresses  three  key  areas; 

— Sound  reuse  policies  and 
procedures 

— Customer  support  and  training 

— Automated  library  system. 


Sound  software  engineering  prac¬ 
tices  are  the  hallmark  of  the  ARC’S 
Software  Reuse  Program.  Each  key 
procedure  is  fully  documented  to  en¬ 
sure  high-quality  reusable  software 
components  (RSCs)  and  repeatable 
processes.  The  procedures  are  domain 
analysis;  reusable  software  compo¬ 
nent  identification,  evaluation  and 
preparation;  configuration  manage¬ 


ment;  quality  assurance;  and  library 
population  and  user  extraction. 

These  reuse  procedures  can  be  fully 
integrated  into  the  software  develop¬ 


ment  life  cycle,  thereby  institutional¬ 
izing  software  reuse  as  part  of  the 
organization’s  development  process. 
This  integration  marks  the  beginning 
of  a  change  in  the  way  software  is 
developed— from  “line-by-line”  to 
“component-by-component.” 

The  ARC  provides  direct  support 
and  hands-on  training  in  domain  analy¬ 


sis,  which  often  will  be  a  critical  “first 
step”  in  achieving  maximum  benefits 
possible  from  software  reuse.  These 
labor-intensive  analysis  activities  fo¬ 
cus  on  identification  of  similarities 


FIGURE  1 .  RSC  Certification  Process 
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and  differences  among  related  sys¬ 
tems  and  provide  the  basis  for  the 
sharing  of  reusable  software  compo¬ 
nents  (Figure  1).  The  ARC'S  domain 
analysis  process  will  evolve  as  it  is 
repeatedly  applied  within  Army  and 
DOD  reuse  efforts,  and  in  response 
to  technology  advances.  This  pro¬ 
cess  is  being  used  and  validated  as 
part  of  ARC'S  FY92  reuse  initiative 
within  the  Program  Executive  Office, 
Standard  Army  Management  Infor- 


nents.  The  library  system  guides  ARC 
engineers  in  application  of  rigorous 
software  engineering  procedures,  strict 
configuration  management,  and  high- 
quality  assurance  during  component 
certification  and  maintenance.  A  to¬ 
tal  of  1,401  reusable  software  compo¬ 
nents,  representing  more  than  1  mil¬ 
lion  lines  of  code,  have  been  certified 
and  are  available  within  the  library. 

Reusable  Ada 


ings. 

As  software  development  costs  con¬ 
tinue  to  skyrocket,  it  will  become  in¬ 
creasingly  imperative  that  program 
managers  evaluate,  and  pursue,  the 
opportunities  for  software  reuse  within 
their  development  efforts.  Reuse  ben¬ 
efits  can  include: 

— More  reliable  and  higher-quality 
systems 


mation  Systems  (PEO-ST AMIS).  ' 

On-Site  Support  \ 

The  ARC  staff  can  y  ^ 

provide  on-site  support 
and  training  in  selection.  \ 
comparison  and  download  \ 
of  a  range  of  reusable  soft-  JP 

ware  components.  These  ® 

components  will  have  been  classified,  ^1 
certified  and  evaluated  in  terms  of 
reusability,  complexity  and  other  quali-  ' 

tative  measures. 

Other  support  includes  reuse  plan¬ 
ning,  reuse  engineering  support  and 
other  program/project  assistance.  The 
ARC  staff  can  work  within  specific 
domains,  or  “families"  of  pro-  Ar 

grams,  to  develop  generic  ar- 
chitectures  and  domain  mod- 
els;  to  identify  specific  reuse  K  ^ 
opportunities  and  high-de-  ^ 

mand  components;  identify 
and  recommend  potential  donor-client  ponents  fror 
matchups:  and  develop  reuse  imple-  Military  Corr 
mentation  schedules.  The  staff  can  tern  (VWVMC 
work  with  individual  programs  to  as-  (AWIS)  Prog 
sist  in  mapping  system/generic  archi-  creased  the  [ 
lectures;  incorporating  software  reuse  tion  software 
into  the  design;  locating  and  extract-  layered  arch 
ing  reuse  components;  integrating  re-  AWIS  is  pro 
usitble  components:  and  reengineering  applications : 
and  re.erse  engineering  existing  sys-  tains  comme 
terns.  data  base,  gr 

ternal  interfa 

The  ARC  library  system  is  the  cor-  utilities.  Inc 
nerstone  of  the  ARC  operation.  Much  mon  service  1 
more  than  a  repository,  it  is  an  inter-  tion  of  it)  witl 
active  library  system  that  will  support  similar  requi 
users  in  analysis,  identification  and  would  provk 
retrieval  of  reusable  software  compo-  terms  of  cosi 


Components 

In  addition,  ARC 
personnel  are  certify- 
k  ing  and  installing  a 
\  large  number  of  re- 
\  usable  Ada  com¬ 


ponents  from  the  Army  Worldwide 
Military  Command  and  Control  Sys¬ 
tem  (VVWMCCS)  Information  System 
(AWIS)  Program.  The  AWIS  has  in¬ 
creased  the  portability  of  its  applica¬ 
tion  software  through  utilization  of  a 
layered  architectural  approach.  The 
AWIS  is  providing  the  ARC  with  its 
applications  support  layer,  which  con¬ 
tains  common  service  interfaces  for 
data  base,  graphic  user  interface,  ex¬ 
ternal  interface  manager  and  various 
utilities.  Incorporation  of  this  com¬ 
mon  service  layer  (or  some  major  por¬ 
tion  of  it)  within  other  systems  having 
similar  requirements  and  standards 
would  provide  significant  benefits  in 
terms  of  cost  avoidance  or  cost  sav¬ 


— Software  already  tested  and 
certified  by  the  ARC 

— Faster  delivery  of  system  software 

— Lower  software  development  and 
maintenance  costs 

— Cost  projections  more  accurate 

— Cost  models  show  reuse  code 
is  much  cheaper  than 
developed  code 

Y  —System  easier  to 

Vfcgy  upgrade  if  reuse 
planned  In. 

Proven  Capability 

/ 

3  The  ARC  has  the  tech¬ 
nology  and  proven  capabil¬ 
ity  to  assist  program  manag¬ 
ers  in  integrating  reuse  within 
their  software  development  pro¬ 
cess.  Supporting  the  Department  of 
the  Army  and  DISA/CIM,  the  ARC 
will  continue  to  provide  an  expand¬ 
ing  range  of  reuse  services  that  include 
domain  analysis,  reuse  engineering 
support,  reuse  familiarization  and  train¬ 
ing,  and  component  certification  and 
reengineering. 

For  more  information  or  to  obtain 
a  copy  of  the  ARC  General  Informa¬ 
tion  or  New  User  Packet  write  or  call: 

Army  Reuse  Center,  USAISSDCW, 
Attn;  ASQB-IWS-R,  Stop  H-4,  Ft. 
Belvoir.VA  22060-5426,(703) 
285-6272,  DSN  356-6272,  Fax  (703) 
285-6377. 
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EA  STRATEGY 


EVOLUTIONARY 
ACQUISITION  AND  DOD’S 

REVISED 

ACQUISITION  STRATEGY: 

The  Defense  Systems  Management  College — 
DOD’S  Agent  For  Change 

Edward  Hirsch 

Brigadier  General,  U.S.  Army  (ret.) 


w  hen  Mr.  Donald  I.  Yockey, 

the  Under  Secretary  of  De¬ 
fense  for  Acquisition,  announced  the 
Department’s  new  acquisition  strat¬ 
egy  on  May  20. 1992,  the  event  marked 
the  end  of  intensive  developmental 
planning  efforts.  It  also  was  the  be¬ 
ginning  of  equally  intensive  efforts  to 
ensure  the  strategy  would  be  imple¬ 
mented  effectively  and  efficiently. 

The  new  strategy  recognizes  the 
significant  recent  changes  in  the  na¬ 
tional  security  environment.  It  em¬ 
phasizes  research,  development,  Ad¬ 
vanced  Technology  Demonstrations, 
technology  insertion,  continuous  im¬ 
provement  of  existing  systems  and 
components — and  the  fact  that  there 
will  be  fewer  new  major  systems  pro¬ 
duced  in  fewer  quantities  than  in  the 
past.  The  cooperation  of  the  three 
major  players  in  this  new  and  flexible 
acquisition  process  is  essential  to  its 

Mr.  PonalJ  I.  Yockey  at  right. 


General  Hirsch  is  a  member  of  the 
Executive  Institute  and  Corporate  Board 
of  the  Defense  Systems  Management 
College. 


The  new  strategy.., emphasixes  research, 
development,  Advanced  Technology 
Demonstrations,  technology  insertion,  continuous 
improvement  of  existing  systems  and 
components-^and  the  fact  that  there  will  be  fewer 

produced  in  fewer  quantities 
than  in  the  past. 


Team  Building  to  Make  It 
Work 


success.  The  executive  and  legisla¬ 
tive  branches  of  government  must  work 
together  and  in  harmony  with  that 
most  essential  contributor  to  the  ac¬ 
quisition  process,  industry. 


The  required  level  of  cooperation 
among  these  three  stakeholders  may 
not  yet  have  been  achieved;  however, 
real  progress  has  been,  and  is  being 
made  toward  that  end.  Two  impor¬ 
tant  initiatives,  reflective  of  this  spirit 
of  cooperation,  appeared  in  the  FY 
1991  Authorization  Act  (PL  101-510). 
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The  first.  Section  800,  directed  DOD 
establish  an  Advisory  Panel  on  Stream¬ 
lining  and  Codifying  Acquisition  Laws 
under  the  sponsorship  of  the  Defense 
Systems  Management  College.  The 
Panel  has  as  its  purpose  to: 

( 1 )  Review  acquisition  laws 
with  a  view  toward  stream-  ^ 

lining  the  acquisition  pro-  \ 

cess;  (2)  Recommend  the  re- 
peal  or  amendment  of  laws 
the  Panel  feels  are  unnec- 
essary  for  the  establish-  g 
ment  and  administration 
of  buyer  and  seller  relationships  in 
procurement;  and  (3)  Prepare  a  pro¬ 
posed  code  of  relevant  acquisition  laws. 
This  effort  is  characterized  by  the  ac¬ 
tive  cooperation  and  personal  par¬ 
ticipation  of  members  of  Congress, 
key  staff  personal,  DOD.  senior  rep¬ 
resentatives  from  industry,  the  legal 
profession  and  academia.  It  has  the 
potential  to  eliminate  or  reduce  what 
appears  to  many  as  the  principal  leg¬ 
islative  roadblocks  to  true  coopera¬ 
tion  among  the  three  participants  in 
the  acquisition  process. 

The  second  legislative  initiative  is 
Section  809  of  the  same  public  law. 
This  section  authorizes  DOD  to  iden¬ 
tify  up  to  six  major  programs  as  Pilot 
Programs  to  conduct  business  in  ac¬ 
cordance  with  standard  commercial, 
industrial  practices.  The  DOD  may 
request  a  waiver  or  limitation  of  any 
provision  of  law  it  considers  appro¬ 
priate.  This  on-going  action  also  en¬ 
joys  the  complete  cooperation  of  the 
three  stakeholders  in  the  process.  It 
has  the  potential  to  not  only  increase 
the  effectiveness  and  efficiency  of  the 
acquisition  process,  but  to  enhance  it 
by  exploiting  commercial  practices  to 
a  greater  degree  than  is  now  the  norm. 

However,  successful  implementa¬ 
tion  of  the  new  strategy  demands  in¬ 
creased  cooperation  among  the  par¬ 
ticipants. 

No  Need  for  a  Paradigm  Shift 

The  principal  imperatives  behind 
the  previous  acquisition  process  were 


^  Command  and 

I- 

Control 

An  evolutionary 
acquisition  strategy  is 
>i  well-suited  to  high 

technology  and 
software  intensive 
programs  where 
requirements  beyond  a 
^  core  capability  can 

generally,  but  not 
'  specifically,  be 

defined. 


the  threats  perceived  to  be  generated 
by  the  existence  of  the  Soviet  Union 
and  the  need  to  cope  with  them — 
quickly.  That  process,  developed  over 
time,  proved  to  be  adequate  to  the 
task.  Essentially,  it  assumed  that  if  a 
major  defense  weapons  system  was 
approved  for  Concept  Demonstration, 
it  would  ultimately  be  approved  for 
production.  The  new  flexible  acqui¬ 
sition  strategy  continues  to  support 
that  view  as  well  as  the  requirement 
for  full  funding  of  the  program.  It 
also  acknowledges  the  possibility  of 
program  termination  prior  to  produc¬ 
tion  and  subsequent  diversion  of  pro¬ 
gram  funds  to  other  activities.  The 
emphasis  shifts  from  production  to 
meet  an  all-important,  time  critical 


initial  operational  capability,  to  re- 
T  ducing  risks  by  increased  use  of 
1  advanced  technology  demonstra- 
1  tions  prior  to  the  Demonstration/ 
V  Validation  Phase. 

Hovvever,  increased 
emphasis  on  risk  reduc- 
tion  activities  is  demanded 
W  throughout  the  acquisition 
1  process  as  is  the  early  and 
1  continuous  involvement  of  the 
_ 1  user  with  the  acquiring  com¬ 
munity.  This  emphasis  con¬ 
stitutes  a  subtle  but  significant  change 
which  impacts  the  stakeholders  in  the 
process.  Fortunately,  no  new  legisla¬ 
tion  is  required  to  accommodate  this 
new  strategy.  If  the  legislative  ac¬ 
tions  required  and  authorized  by  PL 
101-510  come  to  fruition,  the  legal 
basis  for  the  acquisition  process  will 
be  simplified  and  facilitated.  Con¬ 
gress  needs  only  to  continue  to  be 
receptive,  understanding  and  respon¬ 
sive  to  the  changing  needs  of  DOD 
and  industry  as  they  strive  to  operate 
within  the  changing  environment.  The 
Department  of  Defense  and  industry 
on  the  other  hand,  operating  within 
the  policy  guidelines  established  by 
the  Department’s  5000  series  of  di¬ 
rectives  and  instructions,  must  exploit 
the  flexibility  inherent  in  those  guide¬ 
lines  and  modify  their  approach  to 
acquiring  many  types  of  weapons  sys¬ 
tems.  The  template  for  such  modifi¬ 
cation  exists  and  is  currently  identi¬ 
fied  in  the  5000  series  as  Evolutionary 
Acquisition  (EA). 

Evolutionary  Acquisition — 
Permitted,  Not  Preferred 

The  5000  series  of  DOD  directives 
and  instructions  wisely  devotes  sub¬ 
stantial  space  to  define  and  then  re¬ 
quire  the  application  of  the  concept 
of  Evolutionary  Requirements  Defi¬ 
nition.  The  series  recognizes  that  op¬ 
erational  performance  requirements 
for  a  new  acquisition  start  must  evolve 
from  broad  operational  capability 
needs  to  detailed  system-specific  per¬ 
formance  requirements.  However, 
DODD  5000.1  does  not  identify  or 
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define  EA.  It  is  only  in  DODl  5000.2 
that  EA  is  addressed  as  an  alternative 
acquisition  strategy  that  should  be 
considered  for  systems  where  require¬ 
ments  refinements  are  anticipated  or 
where  a  technology  risk  or  opportu¬ 
nity  discourages  immediate  implemen¬ 
tation  of  a  required  capability.  It  states 
that: 

Evolutionary  acquisition  is  an  ap¬ 
proach  in  which  a  core  capability  is 
helded,  and  the  system  design  has  a 
modular  structure  and  provisions  for 
future  upgrades  and  changes  as  re¬ 
quirements  are  refined.  An  EA  strat¬ 
egy  is  well  suited  to  high  technology 
and  software  intensive  programs  where 
requirements  beyond  a  core  capabil¬ 
ity  can  generally,  but  not  specifically, 
be  defined.  This  approach  is  described 
in  loint  Logistics  Commanders  Guid¬ 
ance.  Evolutionary  Acquisition,  An  Al¬ 
ternative  Strategy  for  Acquiring  Com¬ 
mand  and  Control  (C2)  Systems. 

In  essence.  DOD  requires  an  evo¬ 
lutionary  approach  to  requirements 
generation,  and  permits  an  evolution¬ 
ary  approach  to  the  development  and 
acquisition  processes.  The  new  ac¬ 
quisition  strategy  creates  an  environ¬ 
ment  in  which  EA  can  not  only  make 
a  significant  contribution  to  enhanc¬ 
ing  effectiveness  and  efficiency  of  the 
process,  but  can  become  the  preferred 
approach  to  acquiring  most  weapons 
systems. 

Evolutionary 
Acquisition — 

The  Joint  Logistics 
Commanders  View 

In  March  1987.  the  ILCs  in  coop¬ 
eration  with  the  Defense  Systems 
Management  College,  published  their 
guidance  recommending  the  use  of 
an  EA  strategy  in  acquiring  sys¬ 
tems.  They  further  stated  that  while 
their  guidance  was  aimed  specifically 
at  the  use  of  an  EA  strategy  in  acquir¬ 
ing  C2  systems,  "...the  principles  dis¬ 
cussed  may  also  be  applicable  to  the 
acquisition  of  other  kinds  of  systems....” 
In  May  1992.  the  ILCs  reaffirmed  that 


view.  In  a  letter  to  the  Commandant, 
they  requested  that  DSMC  work  with 
them  to  update  the  1987  document 
and  expand  the  guidance  on  EA  to 
include  as  many  types  of  defense  sys¬ 
tems  as  possible.  Clearly,  during  the 
five  years  that  elapsed  since  they  origi¬ 
nally  endorsed  EA  as  a  viable  and 
recommended  strategy,  the  I  EC’s  were 
convinced  that  it  vvas  equally  viable 
for  systems  other  than  command  and 
control. 

Evolutionary  Acquisition — 
Now  More  Than  Ever 

The  Department’s  revised  acquisi¬ 
tion  strategy  clearly  states  the  require¬ 
ment  for  a  more  robust  science  and 
technology  program  which  can  pro¬ 
duce  mature  technology  and  innova¬ 
tive  ideas  related  to  manufacturing 
processes.  It  is  equally  clear  in  its 
demand  that  acquisition-system  ac¬ 
tivities  be  undertaken  only  when:  “( 1 ) 
The  technologies  have  been  demon¬ 
strated.  thoroughly  tested,  and  shown 
to  be  producible;  (2)  There  is  a  clear 
and  verified  military  need  for  the  new 
system  or  system  upgrade;  (3)  The 
new  system  or  system  upgrade  is  cost- 
effective.”  These  requirements  dic¬ 
tate  a  new.  close  and  continuing  rela¬ 
tionship  among  the  science  and 
technology  community,  the  developjer, 
the  tester,  the  supporter  and  the  user. 

The  EA  approach  was  conceived 
to  develop  and  nurture  just  such  a 
relationship.  It  is  comprised  of  the 
following  key  elements: 

•  A  concise  statement  of  operational 
concepts  and  requirements  for  the 
full  system. 

•  A  general  description  of  the 
functional  capability  desired  for 
the  full  system. 

•  A  flexible,  well-planned  overall 
architecture,  to  include  process 
for  change,  which  will  allow  the 
system  to  be  designed  and 
implemented  in  an  incremental 
way. 
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•  A  plan  for  incremental  achieve¬ 
ment  of  the  desired  total  capabil¬ 
ity. 

•  Early  definition, funding,  develop¬ 

ment,  testing,  fielding,  support¬ 
ing  and  operational  evaluation  of 
an  initial  increment  of  operation¬ 
al  capability. 

•  Sequential  definition,  funding, 
development,  testing,  fielding, 
supporting  and  operational  eval¬ 
uation  of  additional  increments 
of  operational  capability. 

•  Continual  dialogue  and  feedback 
among  u  ers,  developers,  support¬ 
ers  and  tesk  s. 

•  Use  of  the  “Build  a  little.  Test  a 
little.  Field  a  little"  development 
philosophy,  which  should  result 
in  timely  fielding  and  support  of 
each  increment  of  operational 
capability. 

•  Use  of  flexible  system  architec¬ 
ture,  which  should  facilitate  evo¬ 
lutionary  enhancement  and  ex¬ 
pansion  of  the  system  while  the 
mission  continues  to  be  support¬ 
ed. 

EA  Meets 

All  the  Demands 

Of  the  Revised  Acquisition 

Strategy 

•  EA  operates  within  the  existing 
acquisition  process — it  conforms 
to  the  5000  series  of  directives 
and  instructions. 

•  EA  is  an  event-driven,  not  a 
calendar-driven  approach. 

•  EA  is  characterized  by  a  “Show- 
Me”  attitude  that  results  in 
maturity  early-on  in  the  acquisition 
cycle. 

•  EA  requires  full  funding  for  each 
increment  of  operational 
capability  prior  to  approval  for 
development. 
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•  EA  supports  the  view  that  older, 
capable  platforms  should  be  up¬ 
graded  with  advanced  components 
to  enhance  mission  accom¬ 
plishment. 

•  EA,  properly  applied,  delays 
system  obsolescence. 

•  EA  is  designed  to  answer  the  three 
questions  critical  to  all  acquisition 
programs — Do  we  need  it?  Will 
it  Work?  Is  it  cost  effective? 

•  EA  can  provide  industry  a  pay  as 
you  go  capability  in  design  and 
development  without  dependance 
upon  getting  well  in  production. 

EA  Places  Unique  Demands 
Upon  the  System 

The  key  ingredient  of  an  EA  devel¬ 
opment  and  acquisition  is  the  con¬ 
tinuous,  combined  user-developer- 
tester-supporter  effort  that  must  exist 
throughout  the  system  life  cycle.  It 
provides  the  feedback  loop  essential 
to  success.  Any  reluctance  or  inability 
to  communicate  and  cooperate  on  the 
part  of  even  one  contributor  to  the 
effort  can  generate  almost  insurmount¬ 
able  problems.  The  challenge  to  the 
testing  community  is  particularly 
daunting.  The  testers  must  become 
involved  early  in  the  process,  work 
closely  with  the  users  and  developers 
and  still  maintain  their  objectivity  and 
the  integrity  of  their  own  process. 

Acquisition  leaders  at  the  senior 
decision-making  levels  must  recognize 
that  programmatic  decisions  made 
early  in  the  program  life  cycle  are 
generally  the  most  critical  in  their  im¬ 
pact  upon  cost,  schedule  and  perfor¬ 
mance.  It  is  essential  that  high  qual¬ 
ity,  experienced  p>ersonnel  are  assigned 
to  whatever  entity  is  established  to 
plan  and  execute  the  as  yet  nonexist¬ 
ent  program  in  its  earliest  stages.  The 
normal  approach  of  assigning  junior 
personnel  who  can  be  made  readily 
available  on  a  temporary  basis  is  un¬ 
acceptable.  The  best  must  be  chosen 
early  and  assigned  for  the  long  term 


Evolutionary 
acquisition  is  an 
approach  in  which  a 
core  capability  is 
fielded,  and  the  system 
design  has  a  modular 
structure  and 
provisions  for  future 
upgrades  and  changes 
as  requirements  are 
refined. 


The  contracting  community  must 
exercise  the  flexibility  inherent  in  our 
system  and  recognize  that  unless  some¬ 
thing  is  expressly  prohibited,  it  is  per¬ 
mitted.  Competition  is  an  important 
element  of  the  process:  however,  when 
a  loyal  and  quality  supplier  is  avail¬ 
able,  his  services  must  not  be  sup¬ 
planted  by  a  low  bidder  whose  past 
performance  and  quality  is  question¬ 
able  or  unknown. 

All  of  these  demands  are  attain¬ 
able.  Evolutionary  acquisition  can 
facilitate  the  accomplishment  of  the 
mission  for  which  the  revised  acqui¬ 
sition  strategy  was  designed.  Evolu¬ 
tionary  requirements  generation,  com¬ 
bined  with  evolutionary  acquisition 
can  provide  the  preferred  approach 


to  achieve  the  new  strateg\''s  objec¬ 
tives. 


EDITOR’S  NOTE. 

Evolutionarx'  Acquisition,  An  Alter¬ 
native  Strategy'  for  Acquiring  Command 
and  Control  (C-)  Systems  is  being  re¬ 
vised. 


FOREIGN 

LANGUAGE 

Instruction 

Contract 

The  CACl  Language  Center  has 
been  awarded  a  contract  from  the 
Defense  Language  Institute  (DLl)  to 
provide  foreign  language  instruction 
services  to  Department  of  Defense 
personnel  in  35  languages,  such  as: 
Albanian,  Arabic,  Bulgarian,  Chinese, 
French,  German,  Japanese,  Lingala, 
Hebrew,  Portuguese,  Spanish  and 
Turkish. 

The  CACI  language  training  pro¬ 
grams  enable  American  diplomatic  and 
military  personnel  to  perform  their 
duties  effectively  overseas  by  impart¬ 
ing  foreign  language  skills  and  essen¬ 
tial  cultural  information.  According 
to  Paula  Satisky,  Director  of  CACI’s 
Language  School,  “We  not  only  teach 
the  language,  we  teach  our  students 
to  think  like  native-speakers.  By  train¬ 
ing  DOD  personnel  to  function  opti¬ 
mally  in  foreign  cultures,  we  promote 
clear  communication  between  the 
United  States  and  other  countries  on 
matters  affecting  international  secu¬ 
rity  and  world  peace.” 


